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

[Tobias Grosser]

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.

Sylvestre, is that right?

Cheers,
Tobias