Re: [boost] Library names in system layout on linux

Subject: Re: [boost] Library names in system layout on linux
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-11-09 11:46:05

Vladimir Prus wrote:
> we had discussion about the library names that are produced
> on Linux, with --layout system:
>
> 	http://thread.gmane.org/gmane.comp.lib.boost.build/19529
>
> Two person who package Boost for different Linuxes participated,
> and I think we've agreed on some changes that will make them,
> and hopefully linux users, a bit happier. Now, with --layout=system,
> the libraries are named like this:
>
> 	libboost_filesystem_mt.so
>
> The proposal is to:
>
> 1. Drop 'mt', since most libraries are built with MT on Linux, and don't
> use such special decorations.
>
> 2. Add version number at end, to comply with standard packaging. 
>
> So, we'd create:
>
> 	libboost_filesystem.so.1.38.0
>
> together with a symlink to it, named
>
> 	libboost_filesystem.so

Hi Volodya,

I've written some open-source stuff that uses Boost and the 
inconsistency of library naming between distributions and between 
different versions has been a real pain for me, and for my users.

My main feeling is that I don't care what the libraries are called, as 
long as the naming is consistent.

At present, I'm shipping a Makefile that looks for libboost_thread-mt.  
This seems to keep most but not all people happy.  I have the 
impression that the majority of distributions are shipping libraries 
with -mt suffixes but without the -gcc stuff, while a few are also 
stripping the -mt.  I encourage you to converge towards the current 
majority position.

If you encourage the distributions to drop the -mt suffix, then my code 
will fail to build on platforms where it currently does build.  This 
would be a bad thing.  Since users don't like editing Makefiles I would 
need to find some way to automatically-detect what library name to 
use.  I dislike autoconf, but it seems like the only real choice.

I would also worry that if I link against a version without the -mt 
suffix them I may actually get a non-thread-safe version, since (IIRC) 
the single-threaded libraries don't/didn't (always?) have a -st 
suffix.  This is a "fail dangerous" situation; those users would 
complain that my code crashes randomly.

Having read the thread that you linked to, the strongest argument that 
I have seen in favour of the proposed change is that "other libraries 
don't have things like -mt in their names".  Although that's true it 
doesn't seem vital to me, and it doesn't seem worth breaking code like 
mine in order to fix it.   What problem do you think you are fixing?

(BTW, an alternative it to make Boost all header-only, or for me to 
only use those libraries that are already header-only.  This is quite 
tempting: at present the only non-header-only libraries that I use are 
threads and program-options.  I already have my own alternative to 
boost.threads that implements cancellation the way that I wanted it, 
but it currently doesn't support non-Linux POSIX, and I could easily 
expunge program options.  Hmm, maybe this would be the easiest way to 
make the problems go away...)

Regards,  Phil.