Comment 32 for bug 1725250

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Herald,

I've spoken to our toolchain maintainer ~doko. As far as I understood (which is very little, to be honest) this linker option prevents one from rebinding and changing symbol definitions once one implementation has been loaded. There have been previous cases of code being incompatible in Ubuntu. For example, https://bugs.launchpad.net/ubuntu/+source/xfe/+bug/644645. Also doko cited some python code, which a plugin wound re-bind a new definition of the function, which the original process would not start using as intended. So the fact that "first token implementation wins" and takes over all slots sounds like, opencrypoki is prevented to load and use the functions from subsequent token implementations. I'm not sure if it is reasonable to force tokens to use unique functions names, as most of token code is probably cargo-culted. I thought that it should be possible to rename/prefix the symbols at linktime or at dlopen time or some such. Cause things like fakeroot/faketime do have access to original function names, and new ones, and are able to use both simultaneously. Tracking this thing down, and improving opencryptoki to support linking with -Bsymbolic-functions is imho out of scope to be tracked here, and maybe we should move this to the upstream bug-tracker / upstream mailing list?

For Ubuntu, fixes to make opencryptoki support -Bsymbolic-functions is too invasive for an SRU, and for us, it is preferred to simply ship the "build opencryptoki without -Bsymbolic-functions" as a much smaller/safer SRU.

Regards,

Dimitri.