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 07:53:18

> 
> 
> Vladimir Prus wrote:
> > John Femiani wrote:
> >
> >> NOTE TO SCONS USERS:
> >> Use LIBS=['liblibboost_xyz'] when linking with boost, since scons
> strips
> >> the first lib prefix.
> >
> > Cool :-)
> 
> How do you specify if you want the static or the dynamic lib then?
> 

Using SCons, 
    env.Append(LIBS=['boost_xyz'])
or 
    env.Append(LIBS=['libboost_xyz])
will match the import lib for the DLL (hence my issue).

To link with the _static_ library using SCons, I need
    env.Append(LIBS=['liblibboost_xyz'])

As I said in a much earlier post, I am not sure if I am being bothered
by SCons for stripping my 'ixes, or if I am bothered by boost for
creating libraries I can't link with the way I expected. I posted to the
SCons list asking about this.

> 
> >> Another option would be if static libraries would not include the
'lib'
> >> prefix on windows so that the mingw linker did not get confused.
(This
> >> means the dll import library filenames would need different stems)
> >
> > Hmm, I'm not sure I like this option.
> 
> Me too.

Why not?  What if shared & import libraries (in general) were placed in
a different folder? 

> 
> Btw.: there _is_ another option for naming with the mingw ld resulting
> in strange looking names like:  libxxx.dll.a and the like.
> 
> While it would be possible to come up with such a scheme I doubt it
> will make things easier.
> 
> The main confusion I can see comes from the fact that for gcc people
> the windows (msvc) naming scheme looks strange. But on the other hand
> mingw _is_ a windows compiler, and I think mingw people are trying
> hard to be as compatible as possible with the windows intricacies.
> I feel boost-build should not defeat this, rather support it.
> 

Hmm... but  /mingw/lib is full of .a files, not .lib files.  

I think that the extension should follow the convention of the toolchain
_on_ the platform, it should not just depend on the platform. All the
mingw shared libraries end in .dll, all the static ones end in .a and
start with lib.

> If one really wants *nix names he/she should consider using cygwin
> as an environment.
> 

Then the apps depend on cygwin1.dll or something right? I am using
mingw-g++ to build boost because I will use mingw-g++ to write apps. If
I want gcc4msvc then that should be made explicit IMO. 

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. Requiring -llibxyz works but has a smell, and it gets
smellier when you try do it from SCons (I wonder what happens with
CMake?) The worst thing is that -lxyz works, it just doesn't do what you
think.  At the least, _I_ did not expect the lib would be necessary, and
nor did the build tool I used, and if I had not caught it then I would
have only found out about my problem when I tried to install my program
on a new machine without the dll (too late IMO).

--John