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

Subject: Re: [boost] Library names in system layout on linux
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-11-09 12:50:07

Phil Endecott wrote:

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

How can we reliably figure what is "majority"?

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

The problem is that new users do *not* find adding any decoration all
that nice.

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

That's a topic that was already extensively debated.

- Volodya