[zypp-devel] Shared library for libsatsolver
Hello guys, I have been recently talking to Klaus about this and he asked me to post this on the mailing list. libsatsolver comes with a static library which is against policies of several distributions and anyway, not a good way to distribute code. As the code and especially the ABI is very stable I would say there is no other reason to keep the library static and do a shared one instead. Benefits would be a better integration into other distributions and getting fixes and changes to the distribution without recompiling bindings, etc. Additionally, this shared library is versioned. I attached a patch to this mail and hope it would be committed to the source repository. There are no issues to expect if the linking is done properly. Sincerely, Michael
Hi, On Thu, 21 Apr 2011, Michael Tremer wrote:
Additionally, this shared library is versioned.
Please use symbol versions to explicitely export the things we want to export, instead of simply all global symbols by accident. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Thanks for your reply. Good point. I'm sorry I missed that. As I am not familiar with the internals of libsatsolver, could someone support me with that? Michael On Thu, 2011-04-21 at 14:54 +0200, Michael Matz wrote:
Hi,
On Thu, 21 Apr 2011, Michael Tremer wrote:
Additionally, this shared library is versioned.
Please use symbol versions to explicitely export the things we want to export, instead of simply all global symbols by accident.
Ciao, Michael.
-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Hi, On Thu, 21 Apr 2011, Michael Tremer wrote:
Good point. I'm sorry I missed that. As I am not familiar with the internals of libsatsolver, could someone support me with that?
I've meanwhile forgotten the cmake way of specifying linker argument, but you have to somehow pass "-Wl,--version-script,libsatsolver.ver" to the link command (if using gcc for linking). The file libsatsolver.ver would be written by you and contains a list of all to-be-exported symbols with their associated version, like: % cat example.ver SAT1.0 { global: some_function; some_other_function; local: *; }; (Once you have released such a shared library for good you never change the content of the SAT1.0 section, you instead only ever add more version sections, e.g. to export new symbols). To get to the list of functions that are sensible to export there are two easy strategies: a) start with an empty version script, and add as many symbols as needed until the whole repo and libzypp builds again b) start with the list of symbols that are currently exported without a version script (readelf -W --dyn-syms libsatsolver.so | grep -v UND) and remove all that seem to be intended to be internal when thinking about them. Variant (a) is more fragile of course, because you have to be sure you know all current users of the library, so I would recommend the (b) way. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
This is the result. Works for me. Thanks for your detailed guidelines how to do it. I took b) and nearly all symbols are in. Hopefully someone could verify the patch? On Thu, 2011-04-21 at 15:18 +0200, Michael Matz wrote:
Hi,
On Thu, 21 Apr 2011, Michael Tremer wrote:
Good point. I'm sorry I missed that. As I am not familiar with the internals of libsatsolver, could someone support me with that?
I've meanwhile forgotten the cmake way of specifying linker argument, but you have to somehow pass "-Wl,--version-script,libsatsolver.ver" to the link command (if using gcc for linking). The file libsatsolver.ver would be written by you and contains a list of all to-be-exported symbols with their associated version, like:
% cat example.ver SAT1.0 { global: some_function; some_other_function; local: *; };
(Once you have released such a shared library for good you never change the content of the SAT1.0 section, you instead only ever add more version sections, e.g. to export new symbols).
To get to the list of functions that are sensible to export there are two easy strategies:
a) start with an empty version script, and add as many symbols as needed until the whole repo and libzypp builds again b) start with the list of symbols that are currently exported without a version script (readelf -W --dyn-syms libsatsolver.so | grep -v UND) and remove all that seem to be intended to be internal when thinking about them.
Variant (a) is more fragile of course, because you have to be sure you know all current users of the library, so I would recommend the (b) way.
Ciao, Michael.
participants (2)
-
Michael Matz -
Michael Tremer