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).
Christian.