Re: [Boost-users] [general] boost 1.35.0 library naming and bjam arguments priorities

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-07-12 19:56:48

Roland Schwarz wrote:

> John Femiani wrote:
> > Why not?  What if shared & import libraries (in general) 
> were placed 
> > in a different folder?
> 
> Yes, this would obviously work. But this would require a 
> change of the layout for all other compilers too. It is just 
> that boost has decided on the naming convention some time ago.

Yeah, I wondered about it since the first time I ever built boost.  Your
suggestion of .dll.a for import libraries seems like it would make _me_
happy though, and it shouldn't break anybody else's build (I think). 

> 
> > WRT a concrete examples; I guess my problem was not 
> convincing enough.
> > We shall see if somebody else complains soon. I think that
> > 
> >      $ g++ foo.cpp -dn -lxyz
> > 
> > fails to locate the static lib on windows with the current names, 
> > which seems like a bug.
<snip>
> I cannot easily see how this flag affects our discussion.

s/-dn/-Wl,-dn

I was testing by calling ld directly. It was very late when I sent that
email, I apologize.
In the past I have used -static (without -B) on mingw-g++ and that
seemed to work with boost 1.34.
It was supposed to tell the compiler to look for the static lib instead
of the dll.

> > Requiring -llibxyz works but has a smell,
> Yes the smell of working on windows. 

AFIK, windows & mingw are supported for boost.
 
> I don't know enough of SCons: does this mean SCons cannot 
> handle library naming that is common on windows?
 
Usually it can, boost has found an exception to the rule. I have posted
to Scons list about it after having troubles linking boost.   

> > The worst thing is that -lxyz works, it just doesn't do what you 
> > think.
> So please tell me what I think ;-)

With
  $ g++ foo.cpp -static -lxyz
"One" would think it means "one" will link with the static lib (If I had
used the right g++ option, that is).  It used to mean that for boost.

 
> So far you have not come up with a alternative suggestion that would
> 1) work
> 2) do what you expect
> 3) is compatible with current boost usage.
> 4) does not break my builds

Thank you! That's the problem with the change introduced to 1.35.

Boost 1.34.1 did this:

 boost_xyz.dll 
 boost_xyz.a (import lib)
 libboost_xyz.a (static lib)

That is basically what I tried to say I response to Volodya earlier.
Since I have been trying to link statically, I never had an issue with
the old system. I am guessing (?) that the naming convention was changed
by folks who had a hard time linking dynamically?  Anyhow, the "fix"
breaks MY build (!). 

> Of course I would not be very happy if you break something 
> for everybody else (including me ;-)

The names already changed, and they did break _my_ build. I wouldn't
mind so much if they seamed inherantly better, but I don't understand
the benefit of the changes introduced to 1.35. I think they also caused
problems for the OP.

I propose what you suggested as a possiblility:

   boost_xyz.dll 
   boost_xyz.dll.a (import lib)
   libboost_xyz.a (static lib)

To see if this scheme works, I created a test.cpp
   
   int main(int, char**) {return 0;}

and I created invalid files named:
   xyz.dll
   xyz.dll.a
   libxyz.a

each was actually just text

   hello world!

Then I tried the following:

   $  g++ test.cpp -L.  -lxyz

   <snip>.\xyz.dll.a: file format not recognized; treating as linker
script

Good...

   $  g++ test.cpp -static -L. -lxyz
   <snip>.\libxyz.a: file format not recognized; treating as linker
script

Therefore the scheme seams to work.

It only breaks builds for people who use 
$  g++ test.cpp -L.  -llibxyz

But they would have had to create their script within the last 4 months,
or have been working off of an unreleased version of boost.

For that group, here is a fix:

  C:\boost\lib>  for %F in (lib*.a) do copy %F %~nF.lib

The proposed scheme has the benefit that the g++ command line will not
need to change if I move from mingw on windows to g++ on linux (I hope).

--John