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

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-07-15 14:36:11

Steven Watanabe wrote: 
> Roland Schwarz wrote:
> > John Femiani wrote:
> >> On my sytem, compiling boost with a freshly installed cygwin using 
> >> this
> >> command:
> >> bash-3.2$ bjam --toolset=gcc --build-type=complete 
> --with-filesystem 
> >> stage
> >>
> >> produced
> >>     boost_filesystem-gcc34-1_35.dll
> >>     boost_filesystem-gcc34-1_35.lib
> >>     libboost_filesystem-gcc34-1_35.lib
> >>     (others ommitted)
> >>
> >> So cygwin has the same issue, but with an older compiler 
> than mingw.
> >>
> >>   
> > Hmm, this is strange. Are you sure you are using a bjam executable 
> > that is built for cygwin?
> > I'll investigate, but have to ask for patience, since I will not be 
> > able to look into this before weekend.
> 
> You're using a windows build of bjam, right?  If you add 
> target-os=cygwin it will generate *.a and *.dll.a files.
> 

(If your catching up with this thread I am moaning about the change in
library names from 1.34 to 1.35, and how the new names suddenly cause
dynamic linking even with -static, -Bstatic, or -Wl,-dn options to mingw
g++.  Instead you must be super-diligent to know that _now_ you must use
-llibxyz instead of -lxyz, which is not portable, is aberrant, and at
least the SCons cross platform build system wont even let you do without
yet _more_ hacking. This could break programs in an awful way, because
they may work fine as long as the dll is around, until they break when
you try to drop the exe on a new machine)

Thanks Steven, that's correct. I used the same bjam I had built earlier
using mingw g++, and I did not use the --target-os option because I did
not know about it. 

What I _want_ from both cygwin and mingw is the *.a and *.dll.a files,
since those are the suffixes that work best with the mingw toolchain
(regardless of the 'os'). To reiterate, I contend that since static
libraries and object files go _back_ into the toolchain to be linked,
their suffixes should be designed to work well with a toolchain rather
than an OS. For targets like shared libraries and executables that are
completely built I beleive in os-based extension (eg .dll and .exe or
.so and <none>). I would prefer an option like --target-toolset=gcc,
that works for cygwin _or_ mingw, and perhaps --target-toolset=msvc to
produce *.lib files. The best would be if the default target-toolset was
the same as the one in the --toolset option.

--John