From 1af517323c506e66dcbd2d88ce8a7d4789d75c38 Mon Sep 17 00:00:00 2001 From: Dimitri Fontaine Date: Fri, 18 Apr 2014 22:24:11 +0200 Subject: [PATCH] Attempt to fix the OpenSSL loading situation. For the generated binary to be really portable, we need to be able to open openssl 1.0.1 even when we've been built against openssl 1.0.0. A way to achieve that with SBCL is by forcing the unloading of the lib at image saving time and register a hook to load it again at image init time. Using the proper API, CFFI will happily load the available file for the lib rather than insisting on loading the exact same one than found on the build machine. --- Makefile | 1 + src/hooks.lisp | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+) create mode 100644 src/hooks.lisp diff --git a/Makefile b/Makefile index 4649a1a..94a220a 100644 --- a/Makefile +++ b/Makefile @@ -79,6 +79,7 @@ $(PGLOADER): manifest buildapp --asdf-tree $(QLDIR)/dists \ --asdf-path . \ --load-system $(APP_NAME) \ + --load src/hooks.lisp \ --entry pgloader:main \ --dynamic-space-size 4096 \ $(COMPRESS_CORE_OPT) \ diff --git a/src/hooks.lisp b/src/hooks.lisp new file mode 100644 index 0000000..4249420 --- /dev/null +++ b/src/hooks.lisp @@ -0,0 +1,20 @@ +;;; +;;; At SBCL image startup, we have a situation when the exact pathname for +;;; the OpenSSL shared Object is not to be found at the same location again. +;;; +;;; Hack our way around that by registering hooks to force unloading and +;;; loading the lib at proper times. +;;; +;;; Note: the culprit seems to be qmynd and its usage of :weakly-depends-on +;;; :cl+ssl in its system definition. +;;; + +(in-package #:cl-user) + +#+sbcl +(progn + (push (lambda () (cffi:close-foreign-library 'CL+SSL::LIBSSL)) + sb-ext:*save-hooks*) + + (push (lambda () (cffi:load-foreign-library 'CL+SSL::LIBSSL)) + sb-ext:*init-hooks*))