On Sun, 2018-03-18 at 16:59 +0100, Niels Möller wrote:
Wouldn't it make sense to remove them from the map file as well, and only export symbols starting with nettle_*?
I'm considing it, but it's not trivial. A related option is to move declarations into internal, uninstalled headers.
That would be sufficient. In gnutls I group these internal symbols outside the main version used for symbols. That is:
https://gitlab.com/gnutls/gnutls/blob/master/lib/libgnutls.map#L1244
These are not present in any header, and tests use the internal headers to see them. 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.
First, symbols have underscores for a few different reasons; the symbols I'm renaming here have it only because size is private and it may leak into the abi with some flavors of linking. Otherwise, they're well documented and unlikely to see any incompatible changes.
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.
And there are different kinds of possible uses:
From within the nettle library.
From test and benchmarking executables in Nettle.
From user's experimental code, which don't care much about api or
abi compatibilities with other versions.
Statically linked binaries, e.g, on embedded systems, might access _nettle_secp_256r1 directly to avoid an extra level of indirection and runtime lookup, with no real problem.
Plain applications relying on both api and abi stability.
We need to allow (1) (at least for some of the _nettle_* symbols). We need to strongly discourage (4). For (2) and (3), it would be nice to be liberal, but it might be fine to simply export more symbols in the static library.
Removing declarations from internal header files would allow (1) and (2), and strongly discourage all other use (if anyone adds their own declarations to be able to call internal functions in a library they are using, they ought to understand they're in unsupported territory).
What would it take to hide all _nettle symbols in libnettle.se? Just delete the _nettle_* line in libnettle.map.in
Yes.
regards, Nikos