On Thu, Mar 27, 2008 at 2:20 PM, Marc-Olivier Barre
<[hidden email]> wrote:
> Hi there,
> I found the reason, I am requesting if anyone has an idea on a solution.
> michel lib # objdump -p libjack.so.0.0.28 | grep SONAME
> SONAME libjack.so.0
> michel lib # objdump -p libjack.so.0.7.1 | grep SONAME
> michel lib #
> So we have no soname in the wrapper lib headers. This seems to be part
> of why ldconfig disqualifies libjack.so.0.7.1 as being able to have
> the libjack.so.0 link pointing to it.
> if someone with more experience on these matters has an idea, he is
> very welcome to share :-)
Here goes the ld man page :
When creating an ELF shared object, set the internal
DT_SONAME field to the specified name. When
an executable is linked with a shared object which has
a DT_SONAME field, then when the exe-
cutable is run the dynamic linker will attempt to load the
shared object specified by the DT_SON-
AME field rather than the using the file name given to the linker.
This apparently is used by libtool, scons does not appear to do it out
of the box (none of our scons generated libs have the SONAME set).
Now I have some keywords to google around :-D