[gambit-list] Undefined symbol in c-lambda
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