X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcode%2Fforeign.lisp;h=cac98877fb08550d80f6d91f3e4e8c7d2faeebd5;hb=f9aaac53a4a43ebae198f53079857acb2d628eb0;hp=b289ba639de8c31a0c0be4ef8c81a57fe45c81c1;hpb=7610c1ce46dbf82bd05bc085fd820fd8c5f1758a;p=sbcl.git diff --git a/src/code/foreign.lisp b/src/code/foreign.lisp index b289ba6..cac9887 100644 --- a/src/code/foreign.lisp +++ b/src/code/foreign.lisp @@ -52,7 +52,7 @@ ;;; On any OS where we don't support foreign object file loading, any ;;; query of a foreign symbol value is answered with "no definition ;;; known", i.e. NIL. -#-(or linux sunos FreeBSD OpenBSD) +#-(or linux sunos FreeBSD OpenBSD darwin) (defun get-dynamic-foreign-symbol-address (symbol) (declare (type simple-string symbol) (ignore symbol)) nil) @@ -62,7 +62,7 @@ ;;; work on any ELF system with dlopen(3) and dlsym(3) ;;; It also works on OpenBSD, which isn't ELF, but is otherwise modern ;;; enough to have a fairly well working dlopen/dlsym implementation. -#-(or linux sunos FreeBSD OpenBSD) +#-(or linux sunos FreeBSD OpenBSD darwin) (macrolet ((define-unsupported-fun (fun-name) `(defun ,fun-name (&rest rest) "unsupported on this system" @@ -70,7 +70,7 @@ (error 'unsupported-operator :name ',fun-name)))) (define-unsupported-fun load-1-foreign) (define-unsupported-fun load-foreign)) -#+(or linux sunos FreeBSD OpenBSD) +#+(or linux sunos FreeBSD OpenBSD darwin) (progn ;;; flags for dlopen() @@ -112,7 +112,9 @@ *after-save-initializations*) (defvar *dso-linker* "/usr/bin/ld") -(defvar *dso-linker-options* '("-shared" "-o")) +(defvar *dso-linker-options* + #-darwin '("-shared" "-o") + #+darwin '("-bundle" "-o")) (sb-alien:define-alien-routine dlopen system-area-pointer (file sb-alien:c-string) (mode sb-alien:int)) @@ -174,7 +176,7 @@ ;; that the list isn't guaranteed to be in reverse order of loading, ;; at least not if a file is loaded more than once. Is this the ;; right thing? (In what cases does it matter?) - (dolist (handle *handles-from-dlopen*) + (dolist (handle (reverse *handles-from-dlopen*)) ;; KLUDGE: We implicitly exclude the possibility that the variable ;; could actually be NULL, but the man page for dlsym(3) ;; recommends doing a more careful test. -- WHN 20000825