muthusuba / serf

Automatically exported from code.google.com/p/serf
Apache License 2.0
0 stars 0 forks source link

serf builds with wrong openssl version on OS X #155

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
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 on code.google.com by leor...@gmail.com on 17 Oct 2014 at 4:51