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.
Thanks
Sylvestre
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.
The rationale behind adding the patch level to the soname was to allow
applications to link against a specific LLVM point release.
-Tom
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.
Exactly. Might be some build magic breaking.
The rationale behind adding the patch level to the soname was to allow
applications to link against a specific LLVM point release.
I think it makes total sense.
cheers,
--renato
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.
The link could not be done correctly. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747701
AFAIK, this change in the soname was not intentional.
It is done in tools/llvm-shlib/Makefile
LIBRARYNAME = LLVM-$(LLVMVersion)
Here, we should have done the opposite:
* build libLLVM-3.4.so with libLLVM-3.4.so as soname
* link libLLVM-3.4.so to libLLVM-3.4.1.so
The rationale behind adding the patch level to the soname was to allow
applications to link against a specific LLVM point release.
OK but it is clearly not the expected behavior from the distro POV. We
expect the soname to remain the same if no changes in the ABI are done.
Otherwise, we would have to rebuild all packages depending on libllvm
just to fix that (instead, I hacked the build system to force
libLLVM-3.4.so as soname).
Hoping I am clear here 
Cheers,
Sylvestre
>> 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?
-Tom
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
Cheers,
Sylvestre
>>>> 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
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
>>>>>>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
> >>>> 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.
Hi Sylvestre,
I've pushed this fix to ToT and the 3.4 branch are you able to verify
that it is working as expected now?
Thanks,
Tom
Sorry about the delay. I confirm that it fixed the problem I had with
the soname.
Thanks!
Sylvestre