Nikos Mavrogiannopoulos nmav@redhat.com writes:
Another approach could be to put them into a version which has variable (per release name). That would allow linking with them, but will always break software that uses them.
I think I like this. Should be easy to implement, document and understand.
A version like
NETTLE_INTERNAL_@PACKAGE_VERSION@
in libnettle.map.in would do, I guess? By definition, this gets a new value for every release, and we don't need to care about structure of the version string (major, minor, patchlevel, rcX, whatever).
I guess I'd need to read up a bit on how linker scripts work.
Other symbols, e.g., _nettle_sha256_compress and _nettle_umac_nh, are internal interfaces which might change if nettle gets new or different optimizations.
We can list the ones that are unlike to see incompatible changes and are useful in applications explicitly, and move any others to either local, or to a private version.
Right, we can decide case by case if those symbols should be in installed headers (I think that's ok for the hash *_compress functions), and if so, whether or not they should be document beyond header comments.
Regards, /Niels