[Ecls-list] Re: More build problems ...
rm at mh-freiburg.de
Mon Jan 31 04:40:07 UTC 2005
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
'--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?
> ------------------------------------------------------- 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
More information about the ecl-devel