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

From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-09-27 09:27:52

Davide Bolcioni wrote:
> 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.

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

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

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

-- 
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/