Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
What steps will reproduce the problem?
1. Install openssl on OS X (default /usr/local/ssl)
2. Build serf with OPENSSL path above
3. otool reports libserf-1.1.3.0.dylib uses libssl in /usr/lib (older, system default)
What is the expected output? What do you see instead?
Newly installed libserf file should use newer openssl
What version of the product are you using? On what operating system?
serf 1.3.7, OS X 10.8.5, openssl 1.0.1j
Please provide any additional information below.
1. I installed a newer version of openssl (1.0.1j) to replace the system version (0.9.8). openssl was configured for 64-bit, and set to create shared (.dylib) libs:
$ ./Configure darwin64-x86_64-cc shared
After installation, all openssl files are in /usr/local/ssl by default
2. Trying to build serf using
$ scons OPENSSL=/usr/local/ssl
seems to work, but the gcc instruction at the very end of the build is being given "-L/usr/lib" right before "-L/usr/local/ssl/lib". This causes gcc to use the built-in, older libssl instead of the newer version in /usr/local/ssl/lib. Using
$ otool -L /usr/local/lib/libserf-1.1.3.0.dylib
confirms this.
3. The workaround is to copy/paste that entire last gcc line in the scons build process back into Terminal, remove the "-L/usr/lib" portion, and rebuild. serf can then be installed normally.
4. I don't know if this is a serf issue or a scons issue. Further, gcc looks in /usr/lib/ by default, so it is unclear why it is being specifically called here with an -L switch.
5. The solution might be to either remove the "-L/usr/lib" portion completely, or if it must be there for some reason, have it AFTER "-L/usr/local/ssl/lib"
Original issue reported by leor972