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 by boost. e.g: 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 problems. cheers, domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50