[Ecls-list] Re: More build problems ...

[R. Mattes]

On Fri, 28 Jan 2005 14:36:16 +0100, Juan Jose Garcia Ripoll wrote:

> 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".

Ups, sorry, that's what i actually used. Here is the copy-pasted version
from config.status:

 '--srcdir=/LISP/ecls/src' '--with-clos-streams' '--with-x'
 '--with-cmuformat' '--with-tcp' '--with-clx' '--enable-threads'

>  Also, did you delete the
> build directory before running "configure" again?

No i didn't. I assumed the build setup would take care of this ...
I'll try another compile with a clean build directory.

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

Hmm, but you export the symbol from libecl.so - this get's tricky once 
you start linking against other libraries that import from libecl.so as.
An application that embeds ecl and extends it must have a way to detect
whether it was linked against a threaded version of libecl or not (other-
wise it might reference an undefined symbol). Maybe there needs to be an
libecl as well as a libecl-threaded?

 Thanks RalfD
> Juanjo
> 
> 
> ------------------------------------------------------- This SF.Net
> email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for
> open source databases. Create drag-&-drop reports. Save time by over
> 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download
> a FREE copy at http://www.intelliview.com/go/osdn_nl