I am not sure this sheds any light, but as I was poking around with OpenSSL (which I was ready to reinstall), I found a PROBLEM file which says
* System libcrypto.dylib and libssl.dylib are used by system ld on Mac
+OS X.
NOTE: The problem described here only applies when OpenSSL isn't b
+uilt
with shared library support (i.e. without the "shared" configurati
+on
option). If you build with shared library support, you will have
+no
problems as long as you set up DYLD_LIBRARY_PATH properly at all t
+imes.
This is really a misfeature in ld, which seems to look for .dylib libr
+aries
along the whole library path before it bothers looking for .a librarie
+s. This
means that -L switches won't matter unless OpenSSL is built with share
+d
library support.
The workaround may be to change the following lines in apps/Makefile a
+nd
test/Makefile:
LIBCRYPTO=-L.. -lcrypto
LIBSSL=-L.. -lssl
to:
LIBCRYPTO=../libcrypto.a
LIBSSL=../libssl.a
It's possible that something similar is needed for shared library supp
+ort
as well. That hasn't been well tested yet.
Another solution that many seem to recommend is to move the libraries
/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
directory, build and install OpenSSL and anything that depends on your
build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to thei
+r
original places. Note that the version numbers on those two libraries
may differ on your machine.
As long as Apple doesn't fix the problem with ld, this problem buildin
+g
OpenSSL will remain as is. Well, the problem was addressed in 0.9.8f b
+y
passing -Wl,-search_paths_first, but it's unknown if the flag was
supported from the initial MacOS X release.
This is a little opaque to me I admit, but I guess that there is indeed a weird library problem on Mac OS. |