The attached patch will add symbol versioning in nettle. That would mean that software linked against nettle 3.x will be able to interoperate with libraries that are linked on a previous version of nettle (and vice versa).
You could check the new symbol names with "readelf -Ws libnettle.so"
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
The attached patch will add symbol versioning in nettle. That would mean that software linked against nettle 3.x will be able to interoperate with libraries that are linked on a previous version of nettle (and vice versa).
Thanks. I take it that solves the soname-related problem you reported yesterday? (I hope to be able to respond properly later today).
I think it would be good with some comments in the linker script libnettle.map, explaining when and how to update it. E.g., the "3" in "NETTLE_3", when should that be updated? Should it always follow the soname? If so, maybe we should have a libnettle.map.in and let configure substitute the major number.
How should we handle incompatible changes to internal, undocumented functions? Then I usually bump the minor number only, but not the soname? Maybe it's impossible or unlikely to get two versions with the same soname linked into the same running program, in which case symbol versions don't need any finer resolution than the soname?
Regards, /Niels
On Mon, Nov 24, 2014 at 3:23 PM, Niels Möller nisse@lysator.liu.se wrote:
The attached patch will add symbol versioning in nettle. That would mean that software linked against nettle 3.x will be able to interoperate with libraries that are linked on a previous version of nettle (and vice versa).
Thanks. I take it that solves the soname-related problem you reported yesterday? (I hope to be able to respond properly later today).
The yesterday's problem is solved in git where you have bumped the hogweed's major version number. The problem it is solved by that patch is to software that due to dependencies is linked to both old and new nettle library versions.
I think it would be good with some comments in the linker script libnettle.map, explaining when and how to update it. E.g., the "3" in "NETTLE_3", when should that be updated? Should it always follow the soname? If so, maybe we should have a libnettle.map.in and let configure substitute the major number.
Done in the current patch. That's the rule I follow.
How should we handle incompatible changes to internal, undocumented functions?
With the version script, nothing that is not prefixed with nettle_ or _nettle_ is exported. If you need to export more than that they should be listed in the version script, possibly with a different name (e.g, INTERNALS).
Then I usually bump the minor number only, but not the soname?
In gnutls I change the soname only when API functions are removed, or API functions are changed.
Maybe it's impossible or unlikely to get two versions with the same soname linked into the same running program, in which case symbol versions don't need any finer resolution than the soname?
At least with gnutls in Debian it was actually occurring. There were libraries linked to gnutls 2.12 and applications to gnutls 3.x.
regards, Nikos
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se