Re: [Matlisp-users] Compilation problem with CMUCL

[Raymond T. <to...@rt...>]

>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:

    Nicolas> Raymond Toy <to...@rt...> writes:
    >> 
    >> Ok, before -lm, can you add -lc?  Like so:
    >> 
    >> " -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lc -lm"))))
    >> 
    >> Then try rebuilding.  I hope that takes care of the problem.  If so,
    >> then it's my problem to figure out why configure isn't adding -lc.
    >> 
    >> Ray

    Nicolas> Doesn't work, unfortunately...

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
    Nicolas> /usr/bin/lisp -noinit -eval '(progn (load "start.lisp"))'
    Nicolas> ; Loading #p"/usr/local/src/matlisp/start.lisp".
    Nicolas> Converted SETLOGICALROOT.
    Nicolas> Converted GETLOGICALROOT.
    Nicolas> Converted DEFLOGICALPATH.
    Nicolas> ;; Loading #p"/usr/local/src/matlisp/system.dcl".
    Nicolas> ;; Loading #p"/usr/local/src/matlisp/config.lisp".


    Nicolas> Error in function SYSTEM::LOAD-OBJECT-FILE:
    Nicolas>    Can't open object "/tmp/29938AG0": "/usr/local/src/matlisp/lib/libmatlisp.so: undefined symbol: fstat"

Are you sure that the new lazy-loader is being loaded?  Your output
doesn't really say.

    Nicolas> The problem could be in defsystem, maybe?  I've seen that CMUCL has

I don't think it's defsystem.

    Nicolas> some version now integrated, matlisp has another one, and there is the
    Nicolas> one at CLOCC, ...  How is the connection between those?

CMUCL 18d is removing the very ancient defsystem that it uses.

The one in matlisp is a copy of the defsystem 3.x in CLOCC.  It's
probably a little behind, but should still work.

If you're sure that the right lazy-loader is being used, then, I'll
have to try this on my Linux box at home.  It's not debian, but that
shouldn't matter when building matlisp.

Ray