t...@gmplib.org (Torbjörn Granlund) writes: > We should never forget that the most important aspect of our tests is to > catch miscompilatilons.
If we build static and shared libraries from the same object files (I suspect automake and libtool doesn't do that for us now), testing the static library should detect miscompilations. But not mislinking, including broken link-time optimizations. And even if we don't do that, I would hope that the risk that a miscompiled object file is caught by unit tests of internal functions, but not by the tests of public gmp functions, is pretty low. To make an informed decision, I think it would help to compile a rough list of the functions to hide. > http://www.airs.com/blog/archives/307 Is this 6 year old post still valid? The runtime linker could build some index to avoid extra walks over symbol tables. I guess it would also be useful with some function __attribute__ expressing that "I don't give a damn if pointer comparison for address(es) to this function work according to the C standard". > I wonder if one could edit the .so file and make hidden symbols visible > again. Perhaps objcopy knows how to do that? The point of hidden is to completely remove the symbols from the symbol table in the shared object, right? So to get them back, I guess one would need to reconstruct GOT and PLT entries either from the object files or from debug info. Perhaps one can relink the .so file with some linker flag saying "ignore hidden"? Or simply collect the object files into a static library. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel