From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-09-27 09:27:52
Davide Bolcioni wrote:
> just my 2 cents ...
> Patrick Hartling wrote:
>> * Installs multi-threaded variants of Boost libraries
>> * Installs both debug and optimized versions of all libraries
> I guess linking an executable built against the multi-threaded library
> with a .so built against the single-threaded library is somehow
> detected ?
>> * Allows multiple boost-devel RPMs to be installed in parallel
> I see this as somewhat dangerous. Consider this bug:
> which occurred because code linked against libstdc++5 linked another
> library which was itself linked against libstdc++6, throwing any
> ODR assumptions by either compiler into la-la land. Although stuff such
> as linker namespaces and visibility are meant to address that, they
> introduce platform- and linker-specific magic which should be weighted
> against the simple approach: an executable and all its libraries,
> recursively, constitute a single process image so everything must be
> built against the exact same set of headers and libraries.
I agree with this philosophy, and the bug pointed out here is something that
I have run into more than once myself. I tracked FreeBSD-current for many
years, and any time there was a shared library version bump on libc, libm,
or anything else in /lib or /usr/lib, it meant rebuilding everything in
/usr/local to ensure that all code built thereafter was linked against the
same set of libraries. Using binary-only software from a commercial vendor
usually meant installing a compatibility package for the last stable release
(compat4x for running 5-current for example) which someone had to maintain.
My point is that, while none of this was pretty or fun, I just accepted
keeping shared libraries in order as a fact of life in the world of software
> Now, having a development environment where exactly one development
> package can be installed helps with the above simple approach: just
> rebuild all .src.rpms in this development environment. If you have to
> build for multiple targets, look into chroots, virtual machines, or
> stuff like mock
> instead of relying on developers getting it manually correct every
> single time (OK, in their Makefiles). Having the development package
> chosen once, by the distributor when the distribution is first
> released, also helps different developers to agree on which development
> package to use.
Thanks for the pointer to an interesting tool. It definitely looks like
something that could come in very handy.
>> Basically, the spec file that I posted follows what I understand to be the
>> "normal" way of installing Boost. In other words, the boost and boost-devel
>> RPMs created by this spec file provide a Boost installation as it would look
>> after running 'bjam install --prefix=/usr'.
> This is fine for a single developer in his $HOME, but I am unconvinced
> of its merits in a production system under package management.
You make many good points here, but I am unconvinced that people should be
disallowed from installing parallel boost-devel packages just because
someone might make a mistake. I'd rather give people the option to do it and
let them decide whether it is worth using than prevent it altogether.
-- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk