Hi, 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). Ciao, Michael. 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 ), so 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@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org