Magnus Holmgren <[email protected]> writes:
> Tracking which internal symbols exist on different architectures to avoid
> errors and warnings when generating the symbols files for Debian is a major
> PITA, but I should probably give up on that and simply tag them all
> "optional".
Ignoring internal symbols (based on _nettle prefix or NETTLE_INTERNAL
symbol version sounds right to me). If possible, it would be good to
ensure that no other debian packages depend on them. Hiding them is one
way to achieve that, but maybe there are others?
> But have you considered hiding them?
They are left visible, for benefit of unit tests as well as experimental
code. Not entirely sure which tests would fail with link errors, though
(most tests use only public entry points).
To hide them, I suspect it's easiest to tweak the existing *.map.in
linker scripts (currently used for coarse symbol versioning).
> What you do is to attach
>
> __attribute__((visibility("default")))
>
> to the symbols to be exported (you can of course #define a macro, say EXPORT,
> with this), then compile with -fvisibility=hidden in CFLAGS.
>
> This should be cross-platform, it sounds like, but I'm not 100% sure.
Would at least need a configure test, since it's compiler specific
(supported by gcc and lookalikes). Using EXPORT macros if fairly common
in libraries, and kind-of required for windows dlls, I think. We get
away without it due to the way dlls are built (including linker flags
like --export-all-symbols, --enable-auto-import, --whole-archive,
although it's not entirely clear to me what each of those flags do).
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
