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. 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
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? -Tom> 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 > >
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 Cheers, Sylvestre