[
https://issues.apache.org/jira/browse/SERF-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Branko Čibej resolved SERF-155.
-------------------------------
Resolution: Fixed
Tested on trunk and on the 1.3.x branc; the RPATH for OpenSSL is correct in
both cases.
> serf builds with wrong openssl version on OS X
> ----------------------------------------------
>
> Key: SERF-155
> URL: https://issues.apache.org/jira/browse/SERF-155
> Project: serf
> Issue Type: Bug
> Reporter: Serf Importer
> Priority: Major
> Labels: Priority-Medium, Type-Defect
>
> *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*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
