modules have a soname?

[Simon Josefsson]

I'm tracking down why I get warnings from dpkg-shlibdeps on a package
that builds dlopen modules with libtool.  For reference, a build log is
available here:

https://buildd.debian.org/status/fetch.php?pkg=jabberd2=amd64=2.3.4-1%2Bb1=1446749350

According to dpkg-shlibdeps dlopen modules should not have a soname:

   "A private library (like a plugin) should not have a SONAME and
   doesn't need to be versioned."

See http://linux.die.net/man/1/dpkg-shlibdeps for more text.

However when I build the package manually I can see that libtool does
add a soname to the module:

jas@latte:~/src/jabberd2/sm$ /bin/bash ../libtool  --tag=CC   --mode=link gcc  
-g -O2 -funsigned-char -module -export-dynamic  -o mod_amp.la -rpath 
/usr/local/lib/jabberd mod_amp.lo ../subst/libsubst.la -lssl -lcrypto -lgsasl 
-ludns -lidn -lexpat -lresolv -lcrypt  -ldl -lz
libtool: link: rm -fr  .libs/mod_amp.la .libs/mod_amp.lai .libs/mod_amp.so 
.libs/mod_amp.so.0 .libs/mod_amp.so.0.0.0
libtool: link: gcc -shared  -fPIC -DPIC  .libs/mod_amp.o  -Wl,--whole-archive 
../subst/.libs/libsubst.a -Wl,--no-whole-archive  -lssl -lcrypto 
/usr/lib/libgsasl.so -ludns -lidn /usr/lib/x86_64-linux-gnu/libexpat.so 
-lresolv -lcrypt -ldl -lz  -O2   -Wl,-soname -Wl,mod_amp.so.0 -o 
.libs/mod_amp.so.0.0.0
libtool: link: (cd ".libs" && rm -f "mod_amp.so.0" && ln -s "mod_amp.so.0.0.0" 
"mod_amp.so.0")
libtool: link: (cd ".libs" && rm -f "mod_amp.so" && ln -s "mod_amp.so.0.0.0" 
"mod_amp.so")
libtool: link: ( cd ".libs" && rm -f "mod_amp.la" && ln -s "../mod_amp.la" 
"mod_amp.la" )
jas@latte:~/src/jabberd2/sm$

What is correct here?  Is libtool is doing the right thing in adding the
soname?

/Simon


signature.asc
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: modules have a soname?

[Simon Josefsson]

Russ Allbery  writes:

> Simon Josefsson  writes:
>
>> I'm tracking down why I get warnings from dpkg-shlibdeps on a package
>> that builds dlopen modules with libtool.  For reference, a build log is
>> available here:
>
>> https://buildd.debian.org/status/fetch.php?pkg=jabberd2=amd64=2.3.4-1%2Bb1=1446749350
>
>> According to dpkg-shlibdeps dlopen modules should not have a soname:
>
>>"A private library (like a plugin) should not have a SONAME and
>>doesn't need to be versioned."
>
>> See http://linux.die.net/man/1/dpkg-shlibdeps for more text.
>
>> However when I build the package manually I can see that libtool does
>> add a soname to the module:
>
> libtool adds an SONAME unless -avoid-version is passed in the libtool
> arguments.  Unless there's some use for the SONAME, it's generally best
> practice to use -avoid-version when creating plugins.

Thanks.

> In other words, this is probably an upstream Makefile issue rather than a
> problem with either libtool or dpkg-shlibdeps.

Upstream do use -avoid-version in their Makefile.am, but I just noticed
that it might not be used in all places.  I'll double check.

/Simon


signature.asc
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: modules have a soname?

[Simon Josefsson]

Simon Josefsson  writes:

>> In other words, this is probably an upstream Makefile issue rather than a
>> problem with either libtool or dpkg-shlibdeps.
>
> Upstream do use -avoid-version in their Makefile.am, but I just noticed
> that it might not be used in all places.  I'll double check.

It doesn't work even in the cases where upstream's Makefile.am uses
-avoid-version.  Libtool is still adding a -Wl,-soname:

jas@latte:~/src/jabberd2-jas/storage$ /bin/bash ../libtool  --tag=CC   
--mode=link gcc -I../c2s -I.. -g -O2 -funsigned-char -module -avoid-version  -o 
authreg_anon.la -rpath /usr/local/lib/jabberd authreg_anon.lo -lexpat -L../util 
-lssl -lcrypto -lgsasl -ludns -lidn -lexpat -lresolv -lcrypt  -ldl -lz
libtool: link: rm -fr  .libs/authreg_anon.la .libs/authreg_anon.lai 
.libs/authreg_anon.so
libtool: link: gcc -shared  -fPIC -DPIC  .libs/authreg_anon.o   -L../util -lssl 
-lcrypto /usr/lib/libgsasl.so -ludns -lidn 
/usr/lib/x86_64-linux-gnu/libexpat.so -lresolv -lcrypt -ldl -lz  -O2   
-Wl,-soname -Wl,authreg_anon.so -o .libs/authreg_anon.so
libtool: link: ( cd ".libs" && rm -f "authreg_anon.la" && ln -s 
"../authreg_anon.la" "authreg_anon.la" )
jas@latte:~/src/jabberd2-jas/storage$ 

Is this intentional, or should we start to track down how -Wl,-soname
was added and treat that as a bug?  The manual says:

'-avoid-version'
 Tries to avoid versioning (*note Versioning::) for libraries and
 modules, i.e. no version information is stored and no symbolic
 links are created.  If the platform requires versioning, this
 option has no effect.

I don't know whether libtool regards the debian/gnu/linux/elf platform
as requiring versioning or not.

This is libtool 2.4.2 from Debian, if it matters.

/Simon


signature.asc
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: modules have a soname?

[Russ Allbery]

Simon Josefsson  writes:

> I'm tracking down why I get warnings from dpkg-shlibdeps on a package
> that builds dlopen modules with libtool.  For reference, a build log is
> available here:

> https://buildd.debian.org/status/fetch.php?pkg=jabberd2=amd64=2.3.4-1%2Bb1=1446749350

> According to dpkg-shlibdeps dlopen modules should not have a soname:

>"A private library (like a plugin) should not have a SONAME and
>doesn't need to be versioned."

> See http://linux.die.net/man/1/dpkg-shlibdeps for more text.

> However when I build the package manually I can see that libtool does
> add a soname to the module:

libtool adds an SONAME unless -avoid-version is passed in the libtool
arguments.  Unless there's some use for the SONAME, it's generally best
practice to use -avoid-version when creating plugins.

In other words, this is probably an upstream Makefile issue rather than a
problem with either libtool or dpkg-shlibdeps.

-- 
Russ Allbery (ea...@eyrie.org)  

___
https://lists.gnu.org/mailman/listinfo/libtool