[#LIB-33] autotools/cmake create different libraries on BSD - MusicBrainz JIRA

libdiscid

autotools/cmake create different libraries on BSD

Created: 05/Mar/13 01:06 AM Updated: 07/Mar/13 10:46 AM Resolved: 05/Mar/13 08:30 PM

Component/s:

None

Affects Version/s:

libdiscid 0.3.2, libdiscid 0.4.0

Fix Version/s:

None

Environment:

FreeBSD 8.3, OpenBSD 5.2, NetBSD 6.0

Issue Links:

Relates

This issue is related to:

~~LIB-32~~ make versioning in the build files less error prone

Description

« Hide

For libdiscid 0.3.2 (changed with ~~LIB-32~~ only when indicated)

BSD has problems here:

OpenBSD 5.2: (non-gnu libtool 1.5.26)
- cmake: libdiscid.so.0.3
- autotools: libdiscid.so.3.2 (freebsd-aout?)
FreeBSD 8.3: (GNU libtool 2.4.2)
- cmake: libdiscid.so.0.3.2
- autotools: libdiscid.so.3 (freebsd-elf?)
NetBSD 6.0: (GNU libtool 2.2.6b)
- cmake: libdiscid.so.0.3.2
- autotools: libdiscid.so.3.2 (freebsd-aout?)
- autotools ~~LIB-32~~ libdiscid.so.0.3 (that is a bug in libtool / ltmain.sh)

everything fine with these:

SunOS and Linux: (GNU libtool 2.4.2)
- cmake: libdiscid.so.0.3.2
- autotools: libdiscid.so.0.3.2
Darwin: (libtool has no --version parameter)
- cmake: libdiscid.0.3.2.dylib
- autotools: libdiscid.0.3.2.dylib

NetBSD also has warnings like:
warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
introduced with adding LT_INIT (because other methods are deprecated).

Arch Linux: libtool 2.4.2

GNU/kfreebsd works just like Linux in this regard.

That might also be a problem with cmake on these platforms (or libtool?)
Anyways, they should produce the same files.

Sort Order:

[ Permalink | « Hide ]

Johannes Dewender added a comment - 05/Mar/13 01:07 AM

I did all that testing for ~~LIB-32~~, of course.
That didn't change much so and that one change is probably an upstream bug.

[ Permalink | « Hide ]

Johannes Dewender added a comment - 05/Mar/13 02:04 AM

Like mentioned in ~~LIB-32~~, the BSD variants actually don't like being treated this way by libtool and most packages fix the SOVERSION to be =MAJOR.

[ Permalink | « Hide ]

Johannes Dewender added a comment - 05/Mar/13 11:59 AM

Some interesting links on what happens:

But it doesn't explain why that is chosen to happen.

There are two requests for libtool to have a -soname option (soversion would be enough for me):

[ Permalink | « Hide ]

Johannes Dewender added a comment - 05/Mar/13 08:30 PM

We have an answer in http://stackoverflow.com/questions/15215898/why-is-libtools-current-used-as-soversion-on-bsd-rather-than-major (thanks kepstin).

This mail has lots of information:
https://lists.gnu.org/archive/html/bug-libtool/2011-05/msg00007.html
For NetBSD there is additional information in http://www.netbsd.org/docs/elf.html#elf-rpath

IRIX seems to have similar issues, but we don't support IRIX (directly, only with ~~LIB-24~~):
https://lists.gnu.org/archive/html/bug-libtool/2002-01/msg00007.html

The baseline is:
libtool so versioning is broken on BSD, but used for too long to change it
Most packages use Linux versioning anyways, others run into issues later (and possibly change to linux versioning then).

Closing this as WONTFIX
This difference is for the better.

[ Permalink | « Hide ]

Johannes Dewender added a comment - 07/Mar/13 10:46 AM

Autotools build on Darwin does not return libdiscid.0.3.2.dylib, but only libdiscid.0.dylib.
No difference between -version-info and -version-number, though.

So there is also a difference on Darwin (BSD-like.. somewhat, but uses Mach-O, rather than elf), but the major is the same, so that's fine.