[MacPorts] #46719: openssl: Undefined symbols for architecture x86_64: _ERR_load_OBJ_strings

MacPorts noreply at macports.org
Sun Feb 8 10:22:05 PST 2015


#46719: openssl: Undefined symbols for architecture x86_64: _ERR_load_OBJ_strings
---------------------------+----------------------
  Reporter:  smastracci@…  |      Owner:  larryv@…
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.3.3
Resolution:                |   Keywords:
      Port:  openssl       |
---------------------------+----------------------

Comment (by MichaelThomasSullivan@…):

 I encountered a somewhat similar failure while trying to upgrade to
 openssl-1.0.2, although the specific undefined symbols were different,
 starting with _CRYPTO_THREADID_cmp, although I don't think the precise
 list is pertinent (I can provide the full log if anyone cares).

 This was actually on the second build attempt; the first time failed with:
 {{{
 :info:build ar: creating archive ../libcrypto.a
 :info:build
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
 file: ../libcrypto.a(ebcdic.o) has no symbols
 :info:build
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
 file: ../libcrypto.a(fips_ers.o) has no symbols
 :info:build error:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
 file: ../../libcrypto.a is not an archive
 :info:build
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar:
 internal ranlib command failed
 }}}
 Since after the first failure I tried {{{sudo port clean openssl; sudo
 port upgrade openssl}}} and got quite different errors, I suspected a race
 condition, so I appended {{{use_parallel_build  no}}} to the Portfile,
 repeated the same commands, and this time it built and installed cleanly.

 I didn't try to fully analyze the root cause of the failure with a
 parallel make, but it seems to be due to simultaneously running the ar
 command on same libcrypto.a from both the Makefile in the crypto directory
 and the Makefile of one of its many subdirectories, which is likely to
 lead to non-deterministic behavior.

-- 
Ticket URL: <https://trac.macports.org/ticket/46719#comment:12>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list