Nikos Mavrogiannopoulos <[email protected]> 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
