|
From: Anders F B. <af...@us...> - 2014-01-07 21:03:28
|
Tim Cuthbertson wrote: > Sorry for not chiming in earlier with this (I've been rather busy), but I just tried it out on Fedora 20. Looks like the prebuilt binary is missing a dependency (or maybe it's a distro issue, I can't quite tell): ... > error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory This has been broken/incompatible between Redhat and Debian, since about forever or so... Basically Fedora just makes something up at random: # For the curious: # 0.9.5a soversion = 0 # 0.9.6 soversion = 1 # 0.9.6a soversion = 2 # 0.9.6c soversion = 3 # 0.9.7a soversion = 4 # 0.9.7ef soversion = 5 # 0.9.8ab soversion = 6 # 0.9.8g soversion = 7 # 0.9.8jk + EAP-FAST soversion = 8 # 1.0.0 soversion = 10 %define soversion 10 And then renames the target in the Makefile to match: @@ -10,6 +10,7 @@ SHLIB_VERSION_HISTORY= SHLIB_MAJOR= SHLIB_MINOR= SHLIB_EXT= +SHLIB_SONAMEVER=10 PLATFORM=dist OPTIONS= CONFIGURE_ARGS= @@ -347,7 +347,7 @@ do_$(SHLIB_TARGET): libs="$(LIBKRB5) $$libs"; \ fi; \ $(CLEARENV) && $(MAKE) -f Makefile.shared -e $(BUILDENV) \ - LIBNAME=$$i LIBVERSION=$(SHLIB_MAJOR).$(SHLIB_MINOR) \ + LIBNAME=$$i LIBVERSION=$(SHLIB_SONAMEVER) \ LIBCOMPATVERSIONS=";$(SHLIB_VERSION_HISTORY)" \ LIBDEPS="$$libs $(EX_LIBS)" \ link_a.$(SHLIB_TARGET); \ Supposedly one could just provde some compatibility shim that tries to load either soname ? Or force the user to do some creative symlinking... Sadly, this seems to be the more popular "answer". --anders PS. Maybe not "forever", but surely "decade": http://www.openwall.com/lists/xvendor/2004/03/01/1 |