[Ecls-list] cl-bench problem/oddity with latest ecls-cvs

Juan Jose Garcia-Ripoll jjgarcia at users.sourceforge.net
Sat Sep 8 18:22:38 UTC 2007


I had no problem running the cl-bench script.

2007/9/8, Michael Abshoff <Michael.Abshoff at fsmath.mathematik.uni-dortmund.de>:
> So I compiled ecls
> on an Opteron under Linux in 64 bit mode and so far everything worked very
> well. I installed in a non-standard prefix
> (/tmp/Work/ecls/ecls-20070908-bin/), put bin in $PATH and lib in
> $LD_LIBRARY_PATH and tried my luck with cl-bench: [...]
> despite LD_LIBRARY_PATH=/tmp/Work2/ecls/ecl-20070908-bin/lib/ I get a link
> failure.
>
> So in $ECL_PREFIX/lib: cp -r * /usr/lib64 [not /usr/lib]
>
> But:
>
> > ;;; Loading "/tmp/Work2/ecls/cl-bench/sysdep/setup-ecl.lisp"
> ;;; Loading #P"/tmp/Work2/ecls/cl-bench/defpackage.lisp"
> ;;; Loading #P"/tmp/Work2/ecls/ecl-20070908-bin/lib/ecl/cmp.fas"
> ;;; Loading #P"/tmp/Work2/ecls/ecl-20070908-bin/lib/ecl/sysfun.lsp"
> ;;; End of Pass 1.
> ;;; Note: Replacing variable G49 by its value
> ;;; Calling the C compiler...
> ;;; Note: Invoking external command:
> ;;; gcc  -D_GNU_SOURCE -g -O2 -fPIC  -fstrict-aliasing -Dlinux -O
> "-I/usr/local/include/" -w -c "/tmp/Work2/ecls/cl-bench/ECL001mQnSjX.c" -o
> "/tmp/Work2/ecls/cl-bench/ECL001mQnSjX.o"
>
> ;;; Note: Invoking external command:
> ;;; gcc -o "/tmp/Work2/ecls/cl-bench/ECL001mQnSjX.fas"
> -L"/tmp/Work2/ecls/ecl-20070908-bin/lib/ecl/"
> "/tmp/Work2/ecls/cl-bench/ECL001mQnSjX.o"  -Wl,--rpath,/usr/lib/ecl/
> -shared    -lecl -ldl  -lm   -lgmp

Look at what my system produces (configured with --prefix=$HOME and
installed using "make install")
...
;;; gcc -I.  -g -O2 -fPIC -fno-common  -fstrict-aliasing -Ddarwin -O
"-I/Users/jjgarcia/include/" -w -c
"/Users/jjgarcia/tmp/cl-bench/support.c" -o
"/Users/jjgarcia/tmp/cl-bench/support.o"
;;; Note: Invoking external command:
;;; gcc -o "/Users/jjgarcia/tmp/cl-bench/support.fas"
-L"/Users/jjgarcia/lib/" "/Users/jjgarcia/tmp/cl-bench/support.o"
-bundle    -lecl   -lm
...

If ECL is told the right prefix and let install itself, then it will
always include compiler flags for the directories where the headers
reside and where the DLL is to be found. How did you build/install
your own copy?

BTW, this is with a copy freshly extracted from CVS. If yours was an
update of a very old copy you might have to delete and rebuild,
because ECL now copies the unix directory structure, instead of
putting headers and libraries in nonstandard locations under the
prefix path.

Cheers,

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com




More information about the ecl-devel mailing list