On Tue, 16 Jul 2019, Dan Cermak wrote:
I feel Dan
wants to talks about some very specific static libs, not
about all of them (for which we don't want to change anything for
exactly the reasons already mentioned in this thread). Some static
libs that he (and others?) call bundled. I admit I don't know what
that should be, and why they would be handled different from normal
static libs (i.e. be frowned upon generally). So, if anything, Dan
needs to explain in more detail what he wants, for which things and
for which reasons.
My proposal was prompted by the exiv2 package: exiv2 bundles the XMP SDK
from Adobe (mostly due to historical reasons), builds a static library
out of it and links against the resulting libxmp. This static library
has to be shipped too, as anything linking against libexiv2 should also
link against libxmp. I thought that it would be useful to put libxmp
into the exiv2-devel package and add a Provides: bundled(libxmp) instead
of the additional libxmp-static package.
Ah, okay, for this case such packaging change might make sense. But it
would make even more sense to just not have to deliver the static lib at
all. As I understand it libeviv2 internally calls into libxmp, but the
idea is not, that the whole libxmp interface is available to users as well
(i.e. the user continues to only use the libexiv2 interface, which then
internally might do some of its things with help of libxmp; IOW libexiv2
completely wraps/abstracts the XMP functionality).
The proper fix to this is to include libxmp.a as a whole into libexiv2.so.
The Real Proper Fix would be to then also hide all symbols from libxmp.a
(or alternatively only export a list of wanted symbols from libexiv2.so).
For that libxmp.a must be compiled with -fPIC, but it seems the XMP SDK is
there in source form, so that shouldn't be a problem.
By including libxmp.a (or it's constituent .o files) directly into
libexiv2.so there's no need anymore to ship libxmp.a, so the whole worry
collapses into happiness. For including static libs whole-sale, see the
link editor flag --whole-archive. (Alternatively I wonder why it isn't
enough to simply link libexiv2.so against libxmp.a (after it got built
with -fPIC), which should work out-of-box if libexiv2 doesn't play games
with weak symbols or dlsym on libxmp.a symbols).
PS: when I google a bit I see hints that libexiv2 actually does contain
support for including libxmp whole-sale, and in addition hiding it's
symbols just fine. (e.g. https://dev.exiv2.org/boards/3/topics/2137
I wonder if our packaging of the static libxmp.a is not simply a past
mistake which never got fixed?
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org