explicit_bzero() compatibility function symbol exported in library

[mledford]

While trying to compile Postgresql 13.1 using libressl 3.2.3 as the ssl library on macOS 11 (Big Sur) I discovered that Postgresql's configure thought that macOS has the explicit_bzero() function. This was confusing as macOS 11 does not ship with this function. Looking further into how Postgresql's configure script determines if explicit_bzero() exists on a system it looks like it creates the a program with a call to the function and then tries to compile and link that program. It appears that explicit_bzero() is exported in the libcrypto global symbol table which caused configure to think that it is supported. Later when the headers couldn't be found and the function not defined the compile failed. For now I'm having to hack the configure script to get things to compile but I would rather not.

I think that only API interface functions should be exported if at all possible.

Thank you for all the great work everyone puts into this project!

[busterb]

Thanks, I'll see if we can just directly link libcompat.a into libssl as well and avoid exporting the symbol, though it also sounds like Postgresql's configure script aught to unset LDFLAGS when doing the test as well.

A possible complication post-fix could be Apple appears to still ship 2.8.3 with macOS Big Sur, so I'm not sure when they might pick up the fix at the OS level, but this should help if folks like yourself are using newer versions.

[ryandesign]

This also causes kerberos5 to fail to build for the same reason.

https://trac.macports.org/ticket/66601

[busterb]

We no longer ship with the compatibility functions exported from libcrypto, instead statically linking them in directly, since 3.7.1 or so.