From: Nikodemus S. <tsi...@cc...> - 2003-08-30 22:05:18
|
Calling load-1-foreign screws up alien variables in shared libraries: Here's a test case, plus some gymastics to exercise the bug: 1. First in shell (foo.c can be empty): $ touch foo.c $ gcc foo.c -shared -o foo.so 2. Then in sbcl * (define-alien-variable "environ" (* c-string)) * environ #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X08277AA8 :TYPE (* C-STRING)> ^ note correct address * (load-1-foreign "foo.so") * environ #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X00000000 :TYPE (* C-STRING)> ^ note wrong (NULL) address * (setf sb-alien::*handles-from-dlopen* (reverse sb-alien::*handles-from-dlopen*)) * environ #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X08277AA8 :TYPE (* C-STRING)> ^ note correct address 3. Again in shell $ gcc foo.c -shared -nostdlib foo.so 4. Again in SBCL * (define-alien-variable "environ" (* c-string)) * environ #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X08277AA8 :TYPE (* C-STRING)> ^ note correct address * (load-1-foreign "foo.so") * environ #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X08277AA8 :TYPE (* C-STRING)> ^ note correct address So, when dlsym in sb-alien::get-dynamic-foreign-symbol-address finds environ from the libc linked to foo.so it somehow doesn't get the address right. Or maybe it gets the address right but then SBCL messes it up -- the details are over my head. Cheers, -- Nikodemus |