Re: [boost] Boost RPM spec file: Take 2

From: Davide Bolcioni (davide_bolcioni_at_[hidden])
Date: 2006-09-25 16:13:15

Greetings,
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:

   http://lists.debian.org/debian-devel/2005/09/msg00657.html

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.

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

   http://fedoraproject.org/wiki/Legacy/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.

> 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.

Thank your for your consideration,
Davide Bolcioni
-- 
There is no place like /home.