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

[Tom Stellard]

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.

-Tom

> Cheers,
> Sylvestre
>