[Sbcl-devel] tools-for-build/grovel-features.sh exercises dynamic linker without -ldl

[Tobias C. R. <tc...@fr...>]

Grovel-features.sh is used to enable the flags

  os-provides-dlopen  and  os-provides-dladdr

and for that it compiles test C programs -- but it does not pass `-ldl'
which results in unreferenced symbols error during linkage.

At least on my Ubuntu 9.10 -- explicitly passing `-ldl' is a necessity.

Was that not the case in past? What to do?


The manpage of dlopen etc also uses the `-rdynamic' flag which is
described as follows in the GCC documentation:

  -rdynamic 

    Pass the flag -export-dynamic to the ELF linker, on targets that
    support it. This instructs the linker to add all symbols, not only
    used ones, to the dynamic symbol table. This option is needed for
    some uses of dlopen or to allow obtaining backtraces from within a
    program.

Does anyone know whether it would be worthwhile to build the src/runtime
stuff with that enabled?


Now that I have os-provides-dladdr, the very end of a backtrace looks
like

   27: ((LAMBDA ()))          ;; <-- thunk passed to MAKE-THREAD
   28: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK351]356))
   29: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
   30: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]293))
   31: (SB-THREAD::CALL-WITH-MUTEX ..)
   32: (SB-THREAD::INITIAL-THREAD-FUNCTION)
   33: ("foreign function: call_into_lisp")
   34: ("foreign function: funcall0")
   35: ("foreign function: new_thread_trampoline")
   36: ("foreign function: #xB7FAE80E")

which is quite a bit better than previously:

   27: ((LAMBDA ()))
   28: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK351]356))
   29: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
   30: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]293))
   31: (SB-THREAD::CALL-WITH-MUTEX ..)
   32: ((LAMBDA ()))
   33: ("foreign function: #x806735B")
   34: ("foreign function: #x8052C4D")
   35: ("foreign function: #x805E100")
   36: ("foreign function: #xB7FAE80E")


The WITHOUT-INTERRUPTS / MUTEX cruft is still annoying, but that needs
thought for another day... :-)

What's the thing at #xB7FAE80E that it won't be resolved?

  -T.