[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

modules have sonames (again)

From: Felix Salfelder
Subject: modules have sonames (again)
Date: Tue, 22 Jan 2019 21:39:27 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Dear all.

I recently ran into the situation described in a post from 2015 [1]. On
GNU/Debian, libtool sets the soname in a binary plugin (-module),
regardless of -avoid-version.

As a consequence, dpkg-shlibdeps issues warnings about unresolved
symbols. From dpkg-shlibdeps(1):

the various warnings that you can encounter:
 binary contains an unresolvable reference to symbol sym: it's probably a plugin
  [..] The binary is most likely a plugin and the symbol is probably
  provided by the program that loads this plugin. In theory a plugin
  doesn't have any SONAME but this binary does have one and as such it
  could not be clearly identified as such. [..] If the binary is really a
  plugin, then disregard this warning.

So I get the warnings. But they are slightly misleading and ignoring
warnings is not exactly best practise. Then, dpkg-shlibdeps keeps quiet
if there is no soname in the plugin, and no other change (tried with a
hacked libtool).

It seems apparent that a plugin does not need a soname. Non-libtool
build systems do not usually set it. So I wonder why libtool does it
that way, and whether I should wish for a change in libtool behaviour.

(I'd be happy to know about any other way to deal with the warnings. I
could not find it in the answers to [1], and not much has changed


PS: Please CC, I am not a subscriber.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]