Library names in system layout on linux
Hi, 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 I suspect some folks packaging Boost might not be reading Boost.Build list, so I wanted to mention this plan here. Anybody has objections? - Volodya
----- Original Message ----- From: "Vladimir Prus" <ghost@cs.msu.su> To: "Boost mailing list" <boost@lists.boost.org> Sent: Friday, November 07, 2008 7:05 PM Subject: [boost] Library names in system layout on linux
Hi,
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.
How will you name the single threaded version?
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
Ok for 2 Vicente
vicente.botet wrote:
----- Original Message ----- From: "Vladimir Prus" <ghost@cs.msu.su> To: "Boost mailing list" <boost@lists.boost.org> Sent: Friday, November 07, 2008 7:05 PM Subject: [boost] Library names in system layout on linux
Hi,
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.
How will you name the single threaded version?
The same -- like it is done on Linux. - Volodya
Vladimir Prus wrote:
vicente.botet wrote:
Hi,
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. How will you name the single threaded version?
The same -- like it is done on Linux.
I'm not quite happy with this. I assume, other libraries don't have the configuration flexibility which boost has, therefore reduced mangling is sufficient for them. With boost it can lead to subtle problems when an application begins using the wrong library. This small suffix doesn't complicate the name too much, so I'd like it to be there. As an alternative, we could drop 'mt', but introduce 'st' in single-threaded builds.
Andrey Semashev wrote:
Vladimir Prus wrote:
vicente.botet wrote:
Hi,
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. How will you name the single threaded version?
The same -- like it is done on Linux.
I'm not quite happy with this. I assume, other libraries don't have the configuration flexibility which boost has, therefore reduced mangling is sufficient for them. With boost it can lead to subtle problems when an application begins using the wrong library. This small suffix doesn't complicate the name too much, so I'd like it to be there. As an alternative, we could drop 'mt', but introduce 'st' in single-threaded builds.
Recall, we're talking about --layout=system, which is explicitly meant for system integrators. So it's not a "small suffix", it is "incompatible with system naming of libraries". There is zillion ways to compile any library, so this matter is not specific to boost. It is known that compiled versions of some Boost libraries have different ABI in ST and MT mode. But then, Boost is not one library of such kind. - Volodya
Vladimir Prus wrote:
How will you name the single threaded version? The same -- like it is done on Linux. I'm not quite happy with this. I assume, other libraries don't have the configuration flexibility which boost has, therefore reduced mangling is sufficient for them. With boost it can lead to subtle problems when an application begins using the wrong library. This small suffix doesn't complicate the name too much, so I'd like it to be there. As an alternative, we could drop 'mt', but introduce 'st' in single-threaded builds.
Recall, we're talking about --layout=system, which is explicitly meant for system integrators. So it's not a "small suffix", it is "incompatible with system naming of libraries".
Is it? AFAIK, there are no specific requirements on the library name itself (by which I mean everything between 'lib' and '.so' or '.a'). It can be 'boost_filesystem' or 'boost_filesystem_mt' - I don't see much difference for packaging purpose.
There is zillion ways to compile any library, so this matter is not specific to boost.
It is known that compiled versions of some Boost libraries have different ABI in ST and MT mode. But then, Boost is not one library of such kind.
But why introduce the danger of misuse, especially when there is no such problem now?
Andrey Semashev wrote:
Vladimir Prus wrote:
How will you name the single threaded version? The same -- like it is done on Linux. I'm not quite happy with this. I assume, other libraries don't have the configuration flexibility which boost has, therefore reduced mangling is sufficient for them. With boost it can lead to subtle problems when an application begins using the wrong library. This small suffix doesn't complicate the name too much, so I'd like it to be there. As an alternative, we could drop 'mt', but introduce 'st' in single-threaded builds.
Recall, we're talking about --layout=system, which is explicitly meant for system integrators. So it's not a "small suffix", it is "incompatible with system naming of libraries".
Is it? AFAIK, there are no specific requirements on the library name itself (by which I mean everything between 'lib' and '.so' or '.a'). It can be 'boost_filesystem' or 'boost_filesystem_mt' - I don't see much difference for packaging purpose.
There is zillion ways to compile any library, so this matter is not specific to boost.
It is known that compiled versions of some Boost libraries have different ABI in ST and MT mode. But then, Boost is not one library of such kind.
But why introduce the danger of misuse, especially when there is no such problem now?
The problem now is that names used by boost libraries don't follow system conventions, so a random user, to build against Boost, should use: -lboost_filesystem-<bunch-on-random-tags> It is a big problem in practice. The only wya to fix that is to: - make --layout=system produce undecorated name - Tell all packagers they should use this option. - Volodya
Vladimir Prus wrote:
Andrey Semashev wrote:
Recall, we're talking about --layout=system, which is explicitly meant for system integrators. So it's not a "small suffix", it is "incompatible with system naming of libraries". Is it? AFAIK, there are no specific requirements on the library name itself (by which I mean everything between 'lib' and '.so' or '.a'). It can be 'boost_filesystem' or 'boost_filesystem_mt' - I don't see much difference for packaging purpose.
There is zillion ways to compile any library, so this matter is not specific to boost. It is known that compiled versions of some Boost libraries have different ABI in ST and MT mode. But then, Boost is not one library of such kind. But why introduce the danger of misuse, especially when there is no such problem now?
The problem now is that names used by boost libraries don't follow system conventions, so a random user, to build against Boost, should use:
-lboost_filesystem-<bunch-on-random-tags>
No, just -lboost_filesystem-mt.
It is a big problem in practice.
Well, I guess that's subjective, but that 'mt' suffix is no problem for me, and I would rather have it in order not to mess with library name clashes.
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.
On Sun, Nov 9, 2008 at 11:46, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
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.
This seems like the important point, to me. What if there were a way to specify what you want, and for some program to find whatever matches best?
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.
Suppose there were a boost_link program so that instead, you said something like: `boost_link =static =mt +gcc -stlport thread` And it gave you back the the static, mt version of the lib, preferring gcc and without stlport? (The script would find the shortest filename that satisfies all the conditions.)
Scott McMurray wrote:
On Sun, Nov 9, 2008 at 11:46, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
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.
This seems like the important point, to me. What if there were a way to specify what you want, and for some program to find whatever matches best?
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.
Suppose there were a boost_link program so that instead, you said something like:
`boost_link =static =mt +gcc -stlport thread`
And it gave you back the the static, mt version of the lib, preferring gcc and without stlport? (The script would find the shortest filename that satisfies all the conditions.)
Ideally, that program should be pkg-config. However, it does not support anything like that. And, while a custom solution will solve the 'what is the name of the library?' issue, it won't solve the 'do I have this library?' issue. If you're writing an application using Boost that should work on all Linux flavours, it won't make life much simpler if your application can ask for specific flavour, and be told that it is not installed. It is much better to expect that shared MT build of boost is available, and act with that in mind. - Volodya
Scott McMurray wrote:
What if there were a way to specify what you want, and for some program to find whatever matches best?
pkg-config++ ? The practical issue with that is that after introducing such a program I'd have to wait for N years until it was available in all deployed versions. I do like the pkg-config approach, though it does not work as well for cross-compilation as the alternatives. Phil.
On Mon, 10 Nov 2008, Phil Endecott wrote:
Scott McMurray wrote:
What if there were a way to specify what you want, and for some program to find whatever matches best?
pkg-config++ ?
The practical issue with that is that after introducing such a program I'd have to wait for N years until it was available in all deployed versions.
This is exactly why package-config and its ilk (including many hard-coded makefiles/jamfiles) are "the wrong thing" and autoconf and friends are "the right thing". It is impossible to noncausally satisfy all the needs of a library's users, but it is possible for a library user to develop tests and workarounds for the features they need. Such tests can then be distributed with the program sources and probe the installed libraries. It is then up to the library developer to not complicate the user's life through misfeatures such as library name mangling and no soname versioning. What was wrong with using different install paths to keep build types separate? /end rant - Daniel P.S. I love boost, just hate linking against it. ;)
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
Vladimir Prus wrote:
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"?
Hmm, well I've just checked a Fedora 7 box and it seems to *not* have the -mt suffix. So it's not as clear-cut as I thought. And presumably those Fedora users have been able to edit my Makefile without much help from me... Phil.
participants (7)
-
Andrey Semashev -
dherring＠ll.mit.edu -
Phil Endecott -
Scott McMurray -
vicente.botet -
Vladimir Prus -
Vladimir Prus