From: Domenico Andreoli (cavokz_at_[hidden])
Date: 2007-07-30 02:37:41
On Mon, Jul 30, 2007 at 09:55:45AM +0400, Vladimir Prus wrote:
> Domenico Andreoli wrote:
> > On Mon, Jul 23, 2007 at 11:37:39AM -0400, Neal Becker wrote:
> >> Vladimir Prus wrote:
> >> >
> >> > I think that we should do the following instead:
> >> >
> >> > 1. Generally change build process to no longer produce
> >> > zillion of variants, at least on Linux.
> >> >
> >> > 2. Make sure "system layout" produces exactly that. In particular,
> >> > the "-mt" suffix should disappear. As result, names like
> >> > libboost_program_options.so will be used.
> >> >
> >> > 3. Make "system" layout the default, at least on Linux. Alternatively,
> >> > write a special docs for packages that says: "for packaging Boost, use
> >> > --layout=system"
> >> I think typically linux distros want the version, but not the 'gcc41'
> >> part. We really do need to allow multiple versions, as is common practice
> >> with
> >> other shared libs on linux systems. Since multiple compilers are
> >> uncommon,
> >> distros normally ignore that. These statements are true on
> >> redhat/fedora,
> >> at least. Since boost doesn't provide an option for this, on redhat the
> >> jamfiles were hacked to do it.
> > IIRC there is a C++ ABI standard definition, which should allow mixing
> > binaries and libraries built with complying compilers. I do not know how
> > much widesprhead is its adoption, IIRC gcc complies starting from 3.2.
> > The point is that it might be too early to drop the toolkint encoding
> > in the library decorated soname even under linux. Suppose a icc user
> > builds its application using a Boost library built with gcc. He could
> > spend days of debugging before discover where is the problem.
> > This issue could well be sorted out at the root, discoverying at build
> > time that there is no suitable Boost library to be used with icc.
> How? pkgconfig is of no help, since it apparently does not understand
> "give me libraries to link with when using icc" request.
pkg-config is a de-facto standard but it's still not mandatory :)
it would be enough to have a script, a batch or whatever (a binary built
using bjam!) which invoked with the right parameters (i.e. toolkit,
variant, etc.) is able to build the library name on any system supported
1) boost-config --module=date_time --variant=mt --toolkit=gcc --toolkit-version=4.2 --cxxflags
everything is specified, the script has nothing to invent. c++
precompiler flags are requested.
2) boost-config --module=date_time --variant=st,debug --toolkit=gcc --ldflags
toolkit version is not specified, use default 'gcc'. linker flags are
requested to link to single-threaded debug variant.
3) boost-config --module=date_time --variant=mt,static --libs
toolkit is not specified, on UNIX cxx may be assumed, on Windows an error
is immediately printed. library dependencies are requested (useful when
linking static libraris) to link with static multi-threaded variant.
IIRC some problems might arise with such a script/program if not done
correctly. these problems are correctly handled by pkg-config but
could be also managed by boost-config.
another option would be to propose a modification of pkg-config. Boost
is not the only c++ library here, surely other suffers from the same
-----[ Domenico Andreoli, aka cavok
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk