[jira] [Resolved] (SERF-155) serf builds with wrong openssl version on OS X

["Branko Čibej (JIRA)" <ji...@apache.org>]

     [ 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)