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

[Juan Jose Garcia Ripoll]

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.

Juanjo