[thirdparty/openssl.git] / PROBLEMS

* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.


    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.


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.
Commit	Line	Data
80e1495b	1	* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
fe5eb670 RL	2
	3
	4	NOTE: The problem described here only applies when OpenSSL isn't built
	5	with shared library support (i.e. without the "shared" configuration
	6	option). If you build with shared library support, you will have no
	7	problems as long as you set up DYLD_LIBRARY_PATH properly at all times.
	8
80e1495b	9
0487cb23 RL	10	This is really a misfeature in ld, which seems to look for .dylib libraries
0487cb23 RL	11	along the whole library path before it bothers looking for .a libraries. This
80e1495b RL	12	means that -L switches won't matter unless OpenSSL is built with shared
	13	library support.
	14
	15	The workaround may be to change the following lines in apps/Makefile.ssl and
	16	test/Makefile.ssl:
	17
	18	LIBCRYPTO=-L.. -lcrypto
	19	LIBSSL=-L.. -lssl
	20
	21	to:
	22
	23	LIBCRYPTO=../libcrypto.a
	24	LIBSSL=../libssl.a
	25
	26	It's possible that something similar is needed for shared library support
	27	as well. That hasn't been well tested yet.
	28
ebccb429 RL	29
	30	Another solution that many seem to recommend is to move the libraries
	31	/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
	32	directory, build and install OpenSSL and anything that depends on your
	33	build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
	34	original places. Note that the version numbers on those two libraries
	35	may differ on your machine.
	36
	37
80e1495b RL	38	As long as Apple doesn't fix the problem with ld, this problem building
	39	OpenSSL will remain as is.
	40
e74e9c48 RL	41
	42	* Parallell make leads to errors
	43
	44	While running tests, running a parallell make is a bad idea. Many test
	45	scripts use the same name for output and input files, which means different
	46	will interfere with each other and lead to test failure.
	47
	48	The solution is simple for now: don't run parallell make when testing.