[Openmcl-devel] Error: Can't resolve foreign symbol "sinf"

Sun Dec 11 22:28:54 PST 2011

On Sun, 11 Dec 2011, Otto Diesenbacher wrote:

> Gary Byers <gb at clozure.com> writes:
>
> thanks for your answer!
>
> yep, it gives a null-pointer:
>
> Welcome to Clozure Common Lisp Version 1.8-dev-r15129M-trunk  (LinuxX8664)!
> ? (with-cstrs ((name "sinf"))
>    (#_dlsym #$RTLD_DEFAULT name))
> #<A Null Foreign Pointer>
>
> Stable Release 1.7 works fine:
>
> Welcome to Clozure Common Lisp Version 1.7-r14925M  (LinuxX8664)!

This may be the binary that we distribute and not one that you built
yourself.  (It's the right version to be that, but I have no way of
knowing whether or not that was built locally.  I strongly suspect
that it wasn't.

I had installed Ubuntu 11.10 on a machine here, but hadn't updated
the installed packages since I did so.  The linker (I assume) seems
to have changed; traditionally, if a shared library was referenced
in the call to the linker, the application was linked to refer to
the library (regardless of whether or not it referenced anything that
was defined in that library); some recent change to the linker seems
to cause the library to be quietly omitted if there are no references
to symbols that it defines.

[src/ccl-dev] gb at havoc> ldd lx86cl64
 	linux-vdso.so.1 =>  (0x00007fff3e51d000)
 	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007feceda83000)
 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007feced7ff000)
 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007feced5e1000)
 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feced242000)
 	/lib64/ld-linux-x86-64.so.2 (0x00007fecedcaf000)

If libm.so doesn't show up in ldd's output, we aren't going to be able to
find sinf() or anything else defined in the library.  (You could always
open the library manually via OPEN-SHARED-LIBRAY, but we expect libm.so
to be open on startup.)

On other platforms where we've seen this, a workaround is to simply
reference some symbol ("sinf" or "exp" or ...) defined in the math
library.  That seems to work in this case and seems harmless; I won't
really know if it's indeed harmless until some time after I check in
that change.

I don't know whether the old behavior was documented or intentional
or whether the change is documented or intentional or whether there
are linker options to control it.

> ? (sin .5)
> 0.47942555
>
> just for the records, my system:
>
> uname -a
> Linux brynhild 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> best regards,
> /okflo
>
>> [src/ccl] gb at leadfoot> ccl64
>> Welcome to Clozure Common Lisp Version 1.8-dev-r15129M-trunk  (LinuxX8664)!
>> ? (sin .5)
>> 0.47942555
>> ? (external "sinf")
>> #<EXTERNAL-ENTRY-POINT "sinf" (#x00007F3991506AD0) libm.so.6 #x3000400356CD>
>>
>> We know that those things don't work for you, but don't know why they don't.
>>
>> CCL::RESOLVE-EEP will do something very much like:
>>
>> ? (with-cstrs ((name "sinf"))
>>     (#_dlsym #$RTLD_DEFAULT name))
>> #<A Foreign Pointer #x7F3991506AD0>
>>
>> Does this return a non-null pointer for you ?
>>
>>
>>
>> On Fri, 9 Dec 2011, Otto Diesenbacher wrote:
>>
>>>
>>> Hi CCLers,
>>>
>>> with current ccl r15129 (linuxx86-64), when calling f.e. (sin .5):
>>>
>>> Welcome to Clozure Common Lisp Version 1.8-dev-r15129M-trunk  (LinuxX8664)!
>>> ? (sin .5)
>>>> Error: Can't resolve foreign symbol "sinf"
>>>> While executing: CCL::RESOLVE-EEP, in process listener(1).
>>>> Type :POP to abort, :R for a list of available restarts.
>>>> Type :? for other options.
>>> 1 > :b
>>> (7F62804A3888) : 0 (RESOLVE-EEP #<EXTERNAL-ENTRY-POINT "sinf" {unresolved}  #x3000400356CD> T) 341
>>> (7F62804A38D8) : 1 (FUNCALL #'#<(:INTERNAL CCL::%XERR-DISP)>) 3005
>>> (7F62804A3930) : 2 (FUNCALL-WITH-ERROR-REENTRY-DETECTION
>>> #<COMPILED-LEXICAL-CLOSURE (:INTERNAL CCL::%XERR-DISP)
>>> #x7F6281AE21BF>) 181
>>> (7F62804A3970) : 3 (FUNCALL #'#<CCL::%XERR-DISP> 17507629796830) 549
>>> (7F62804A39A8) : 4 (%PASCAL-FUNCTIONS% 2 17507629796830) 397
>>> *(7F62804A3A10) : 5 (%SINGLE-FLOAT-SIN 0.5) 76
>>> (7F62804A3A70) : 6 (CALL-CHECK-REGS SIN 0.5) 221
>>> (7F62804A3AA8) : 7 (TOPLEVEL-EVAL (SIN 0.5) NIL) 717
>>> (7F62804A3B48) : 8 (READ-LOOP :INPUT-STREAM #<SYNONYM-STREAM to
>>> *TERMINAL-IO* #x3020006B78DD> :OUTPUT-STREAM #<SYNONYM-STREAM to
>>> *TERMINAL-IO* #x3020006B777D> :BREAK-LEVEL 0 :PROMPT-FUNCTION
>>> #<Compiled-function (:INTERNAL CCL::READ-LOOP) (Non-Global)
>>> #x30000050722F>) 2325
>>> (7F62804A3DA8) : 9 (RUN-READ-LOOP :BREAK-LEVEL 0) 157
>>> (7F62804A3DD0) : 10 (TOPLEVEL-LOOP) 101
>>> (7F62804A3DF8) : 11 (FUNCALL #'#<(:INTERNAL (TOPLEVEL-FUNCTION (CCL::LISP-DEVELOPMENT-SYSTEM T)))>) 117
>>> (7F62804A3E18) : 12 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 645
>>> (7F62804A3EB0) : 13 (RUN-PROCESS-INITIAL-FORM #<TTY-LISTENER
>>> listener(1) [Active] #x3020006B66AD> (#<COMPILED-LEXICAL-CLOSURE #
>>> #x3020006B61EF>)) 717
>>> (7F62804A3F48) : 14 (FUNCALL #'#<(:INTERNAL
>>> (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> #<TTY-LISTENER
>>> listener(1) [Active] #x3020006B66AD> (#<COMPILED-LEXICAL-CLOSURE #
>>> #x3020006B61EF>)) 381
>>> (7F62804A3F98) : 15 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 301
>>>
>>> current image is build with (rebuild-ccl :full t)
>>>
>>> best regard,
>>>  /okflo
>>>
>>> --
>>> diesenbacher.net
>>> Dipl. Ing. (FH) Otto Karl Florian Diesenbacher
>>> okflo at diesenbacher.net
>>> http://www.diesenbacher.net/
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>>
>
> -- 
> diesenbacher.net
> Dipl. Ing. (FH) Otto Karl Florian Diesenbacher
> okflo at diesenbacher.net
> http://www.diesenbacher.net/
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>