Consider isolating the `der_*` functions

[atoomic]

Description

I just run into some issues with a compiled binary which was using multiple definitions of der_* functions

In my example these two libraries are providing 'der_*' helpers

• /lib/x86_64-linux-gnu/libhx509.so.5
• 532/lib/perl5/cpanel_lib/x86_64-linux-64int/auto/CryptX/CryptX.so

der_length_integer is available from both libraries
but only der_decode_integer is availabe from CryptX.so

We should consider renaming all the der_* functions with a prefix like tomcrypt_

also reported to heimdal repo as heimdal/heimdal#911

[sjaeckel]

IMO the correct approach would be to hide those symbols when compiling those libs who bundle ltc, and not to rename them.

Renaming them in ltc itself is IMO also not an option.

CC @karel-m

[atoomic]

indeed this seems a fair advice

[karel-m]

I agree with @sjaeckel that renaming those function is just a hack. Similar issue may appear with any other function which name will collide with another library.

To fix the troubles reported by @atoomic (DCIT/perl-CryptX#79) we probably need some kind of linker kung-fu in my perl Module CryptX

[atoomic]

I think we should close this case as I agree there is nothing to do here at the libtomcrypt level. Nothing wrong there.
We should consider hide the symbols when compiling the Perl package.
It seems that using CFLAGS="-Wl,--exclude-libs,ALL -fvisibility=hidden" provides that behavior