[LLVMdev] Name of the libraries + soname? 3.4.1 ?

Tom Stellard tom at stellard.net
Mon May 12 09:01:29 PDT 2014


On Mon, May 12, 2014 at 05:49:22PM +0200, Tobias Grosser wrote:
> On 12/05/2014 17:12, Tom Stellard wrote:
> >On Mon, May 12, 2014 at 04:17:05PM +0200, Sylvestre Ledru wrote:
> >>On 12/05/2014 16:13, Tom Stellard wrote:
> >>>On Mon, May 12, 2014 at 04:05:20PM +0200, Sylvestre Ledru wrote:
> >>>>On 12/05/2014 15:22, Tom Stellard wrote:
> >>>>>On Mon, May 12, 2014 at 08:41:36AM +0200, Sylvestre Ledru wrote:
> >>>>>>Hello,
> >>>>>>
> >>>>>>With the release of 3.4.1, the LLVM library has been renamed from
> >>>>>>libLLVM-3.4.so to libLLVM-3.4.1.so. In parallel, the soname has been
> >>>>>>updated to
> >>>>>>reflect this change.
> >>>>>>
> >>>>>>AFAIK, we kept the ABI compatible from 3.4 to 3.4.1. So, is there any
> >>>>>>reason for doing it?
> >>>>>>This caused some breakages in Debian (basically, breaking some X because
> >>>>>>of mesa could not
> >>>>>>link against LLVM due to the new soname).
> >>>>>>I noticed that we did the same with 3.5.
> >>>>>>
> >>>>>>I am not sure to understand what was wrong with the X.Y naming schema.
> >>>>>
> >>>>>The library was renamed, but a libLLVM-3.4.so symlink was added to point
> >>>>>to libLLVM-3.4.1.so, so I don't think anything should break.
> >>>>Yes but the (distro?) tools relies on the soname for linking and the
> >>>>soname was updated.
> >>>
> >>>Is soname an attribute that is stored somewhere within the shared library, or does
> >>>it refer to the name of the shared object file?
> >>It is stored inside (and built with -Wl,-soname,libfoo.so.0)
> >>For example, in Debian (and Ubuntu), we consider that a library in
> >>/usr/lib/* without a soname is an error.
> >>
> >>Example:
> >>$ objdump -p /usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1 |grep SONAME
> >>   SONAME               libLLVM-3.4.so.1
> >>
> >
> >Ok, this makes sense now, so it does look like a bug in in the LLVM build system.
> >Your suggestion to swap the symlink (i.e. create a libLLVM-3.4.1.so symlink that
> >points to libLLVM-3.4.so) seems like a good one.  I will make this change unless
> >someone objects.
> 
> Just to warn you. Distributors are very sensitive to release
> binaries that change. If you already published files for LLVM 3.4.1,
> those files should be assumed frozen. Anything that changes their
> MD5 sum will cause problems.
> 

We will not be changing the 3.4.1 release binaries.  This fix will go into 3.4.2.

-Tom

> Sylvestre, is that right?
> 
> Cheers,
> Tobias



More information about the llvm-dev mailing list