-If you have any problems with SSLeay then please take the following
-steps:
+* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
- Remove the ASM version of the BN routines (edit Configure)
- Remove the compiler optimisation flags
- Add in the compiler debug flags (-g)
-Note: if using gcc then remove -fomit-frame-pointer before you try
- to debug things.
+ NOTE: The problem described here only applies when OpenSSL isn't built
+ with shared library support (i.e. without the "shared" configuration
+ 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 times.
-If you wish to report a bug then please include the following information
-in any bug report:
- SSLeay Details
- - Version, most of these details can be got from the
- 'ssleay version -a' command.
- Operating System Details
- - OS Name
- - OS Version
- - Hardware platform
- Compiler Details
- - Name
- - Version
- Application Details
- - Name
- - Version
- Problem Description
- - include steps that will reproduce the problem (if known)
- Stack Traceback (if the application dumps core)
+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.
-For example:
+The workaround may be to change the following lines in apps/Makefile.ssl and
+test/Makefile.ssl:
- SSLeay-0.5.1a
- SunOS 5.3, SPARC, SunC 3.0
- SSLtelnet-0.7
+ LIBCRYPTO=-L.. -lcrypto
+ LIBSSL=-L.. -lssl
- Core dumps when using telnet with SSL support in bn_mul() with
- the following stack trackback
- ...
+to:
+ LIBCRYPTO=../libcrypto.a
+ LIBSSL=../libssl.a
-Report the bug to either
- ssleay@mincom.oz.au (Eric and Tim)
-or
- ssl-bugs@mincom.oz.au (mailing list of active developers)
+It's possible that something similar is needed for shared library support
+as well. That hasn't been well tested yet.
-Tim Hudson
-tjh@mincom.oz.au
+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.