Issue Details (XML | Word | Printable)

Key: LIB-33
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Normal Normal
Assignee: Johannes Dewender
Reporter: Johannes Dewender
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
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
 


 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: Ascending order - Click to sort in descending order
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.


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.


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):


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.


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.