Skip to main content
  • Home
  • login
  • Browse the archive

    swh mirror partner logo
swh logo
SoftwareHeritage
Software
Heritage
Mirror
Features
  • Search

  • Downloads

  • Save code now

  • Add forge now

  • Help

  • e4e3df9
  • /
  • PROBLEMS
Raw File
Permalinks

To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.

  • content
  • directory
content badge Iframe embedding
swh:1:cnt:f072449feca8c77565299c1c1522a018e9eedb62
directory badge Iframe embedding
swh:1:dir:e4e3df9a8bf2d9a892d3b45d367483e0df1a3464
PROBLEMS
* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
[NOTE: This is currently undergoing tests, and may be removed soon]

This is really a misfeature in ld, which seems to look for .dylib libraries
along the whole library path before it bothers looking for .a libraries.  This
means that -L switches won't matter unless OpenSSL is built with shared
library support.

The workaround may be to change the following lines in apps/Makefile.ssl and
test/Makefile.ssl:

  LIBCRYPTO=-L.. -lcrypto
  LIBSSL=-L.. -lssl

to:

  LIBCRYPTO=../libcrypto.a
  LIBSSL=../libssl.a

It's possible that something similar is needed for shared library support
as well.  That hasn't been well tested yet.


Another solution that many seem to recommend is to move the libraries
/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
directory, build and install OpenSSL and anything that depends on your
build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
original places.  Note that the version numbers on those two libraries
may differ on your machine.


As long as Apple doesn't fix the problem with ld, this problem building
OpenSSL will remain as is.

ENEA — Copyright (C), ENEA. License: GNU AGPLv3+.
Legal notes  ::  JavaScript license information ::  Web API

back to top