[Ecls-list] More build problems ...

Juan Jose Garcia Ripoll lisp at arrakis.es
Fri Jan 28 07:00:04 UTC 2005

R. Mattes wrote:

>Well, again, a fresh checkout (the last one _did_ compile without
>problems) and the build process stops, this time with the following: 
> > ;;; Invoking external command: gcc -g -O2 -fPIC -D_THREAD_SAFE
> > -fstrict-aliasing -Dlinux -I"/LISP/ecls/src"/h
> > -I"/LISP/ecls/src"/gmp
> > -I"/LISP/ecls/build"/h  -I"/LISP/ecls/build"/h -w -c "ecl.c" -o "ecl.o"
> ;;; Invoking external command: gcc -o "ecl" -L"/LISP/ecls/build" "ecl.o"
>   "-L./"   -Wl,--rpath,/usr/local/lib/ecl/ libecl.so -lpthread -ldl -lm
>Hmm, i should note that i added '--with-threads' to my configure
>invocation. Looking a '' i find that cl_env is being defined
>conditionally when threading is enabled:
The name of the flag is "--enable-threads". Also, did you delete the 
build directory before running "configure" again?

As for the structure reference, I do not see why the current way of 
defining the global environment should be a problem. Whether the flag 
ECL_THREADS is defined or not is decided at compilation time and this 
flag is stored in the header config.h which is loaded before external.h 
Hence when we ECL has been compiled with support for threads, any 
reference to the global environment results in a function call, but for 
single threaded runtimes we can access the fields of the structure with 
a single direct reference. There is no portable way of defining inline 
functions and users need never access the cl_env structure anyway.


More information about the ecl-devel mailing list