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.