Re: More RFH: liblicense: Module symbols "found in none of the libraries"
Asheesh Laroia <asheesh@asheesh.org> writes:
> I want to ask a particular question here: My package (for which I am
> upstream) makes some interesting complaints from dpkg-shlibdeps after it
> builds:
>
> dpkg-shlibdeps: warning: symbol LL_E_MODULE_WRITE_FAIL used by
> debian/liblicense2/usr/lib/liblicense/0.6/io/sidecar_xmp.so found in none
> of the libraries.
> dpkg-shlibdeps: warning: symbol LL_WEBSTATEMENT used by
> debian/liblicense2/usr/lib/liblicense/0.6/io/sidecar_xmp.so found in none
> of the libraries.
> dpkg-shlibdeps: warning: symbol LL_MORE_PERMISSIONS used by
> debian/liblicense2/usr/lib/liblicense/0.6/io/sidecar_xmp.so found in none
> of the libraries.
>
> and so on.
>
> Now, to give some background - these modules do work! liblicense.so is
> responsible for determining e.g. what license a file claims it is
> under. As a user of liblicense, you might call ll_read() on a filename
> you pass in - liblicense detects the file type and dlopen()s a .so that
> handles files of that type.
>
> So this /usr/lib/liblicense/0.6/io/sidecar_xmp.so file is a "module"
> that refers to symbols that are not contained in it. That's expected by
> me - because the symbols it needs are guaranteed to be available when it
> is dlopen()'d by liblicense.so.
>
> So what should I do?
It's quite possible that the right answer is nothing. I thought
dpkg-shlibdeps was supposed to have some logic to ignore this kind of
situation for loadable objects that aren't shared libraries. Is it
possible that this object, despite not being a library, has an SONAME set?
If so, that will confuse dpkg-shlibdeps, I believe, into thinking it's a
shared library and should be checked for such things.
I don't particularly like the habit that plugin authors have of depending
on symbols exported from the loading code, and think that in most cases
it's better to link explicitly with any libraries that the plugin uses.
That dlopen() guarantee isn't as much of a guarantee as people think it
is, and there are options with which you can call it that will cause this
to fail. However, lots and lots and lots of stuff does work this way and
usually doesn't cause problems.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: