12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758 |
- * System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
- [NOTE: This is currently undergoing tests, and may be removed soon]
- This is really a misfeature in ld, which seems to look for .dylib libraries
- along the whole library path before it bothers looking for .a libraries. This
- means that -L switches won't matter unless OpenSSL is built with shared
- library support.
- The workaround may be to change the following lines in apps/Makefile.ssl and
- test/Makefile.ssl:
- LIBCRYPTO=-L.. -lcrypto
- LIBSSL=-L.. -lssl
- to:
- LIBCRYPTO=../libcrypto.a
- LIBSSL=../libssl.a
- It's possible that something similar is needed for shared library support
- 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 their
- 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 building
- OpenSSL will remain as is.
- * Parallell make leads to errors
- While running tests, running a parallell make is a bad idea. Many test
- scripts use the same name for output and input files, which means different
- will interfere with each other and lead to test failure.
- The solution is simple for now: don't run parallell make when testing.
- * Bugs in gcc 3.0 triggered
- According to a problem report, there are bugs in gcc 3.0 that are
- triggered by some of the code in OpenSSL, more specifically in
- PEM_get_EVP_CIPHER_INFO(). The triggering code is the following:
- header+=11;
- if (*header != '4') return(0); header++;
- if (*header != ',') return(0); header++;
- What happens is that gcc might optimize a little too agressively, and
- you end up with an extra incrementation when *header != '4'.
- We recommend that you upgrade gcc to as high a 3.x version as you can.
|