[Ecls-list] Re: More build problems ...
Juan Jose Garcia Ripoll
lisp at arrakis.es
Mon Jan 31 05:04:04 UTC 2005
R. Mattes wrote:
>>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.
I still do not understand the problem. ECL only exports the symbol
cl_env in single-threaded images. If your application was compiled using
a single-threaded ECL, then it can only run using such a DLL. It will
never run with a multithreaded version because many thing change, not
only the list of exported C names, but also array of symbols, the way
values of variables are accessed, etc.
Currently, ECL is not designed for multithreaded and single threaded
images to coexist on the same directories. This is because, as I
mentioned above, the headers and many other things do depend on what
configuration flags you used.
>Maybe there needs to be an
>libecl as well as a libecl-threaded?
Probably, but the issue goes beyond the libraries, and influences the
headers, the cmp.fas module, etc. Currently you have to decide at
configuration time whether you want to go for multithreading or not.
>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).
Applications you compile using ECL can detect whether multithreading is
"on" by checking whether the C macro ECL_THREADS is defined, and whether
the feature :THREADS is present in the Lisp environment.
More information about the ecl-devel