[gambit-list] Undefined symbol in c-lambda

Christian Jaeger christian at pflanze.mine.nu
Wed Jun 25 19:44:02 EDT 2008

Joel J. Adamson wrote:
> /home/joel/lisp/scm/genxic/gsl_genx> gsi gsl_genx
> *** ERROR IN ##main -- /home/joel/lisp/scm/genxic/gsl_genx/gsl_genx.o11:
> undefined symbol: gsl_matrix_get_row
> (load "gsl_genx")


> Now, the obvious problem is that the symbol *is* defined in
> gsl/gsl_matrix.h.  If I comment the function that uses
> gsl_matrix_get_row, then the next one comes up with the same error.
> I've looked at the resulting C file (gsc -c gsl_genx.scm), and
> gsl_genx.h is included.  What am I missing here?

(Note/beware: the following is all from someone who just learnt how the 
unix/gnu toolchain works by need and example and not by detailed study.)

When load complains about an undefined symbol, it's really the dynamic 
linker. It is complaining about a C function/variable the object file is 
requiring, and which the dynamic linker is trying to resolve, but cannot 
find a match; this usually means that (a dependency of the object file 
is not loaded already and) that the object file has been compiled 
without giving gcc -l flags so that it integrates the relevant info for 
loading the dependencies automatically. I think you are missing some 
flag along the lines of "-ld-options -lgsl" to your gsc invocation.

Be aware that these symbols are different from the ones in the header 
files: the header files only exist at compile time, they are telling the 
C compiler about types and some additional info (extern, volatile etc. 
flags). After the object file has been built, resolving symbols is a 
task for the (dynamic or static) linker, not the compiler. In short: 
you're not getting a compiler error, but a linker error (loading an 
object file into Gambit is (an extended form of) dynamic linking).


More information about the Gambit-list mailing list