On 2011-05-14, at 12:28 AM, Kartik Saranathan wrote:
I found the problem is because the ___EXT macro uses the static variable ___local_gstate which is uninitialized in fileio_util.cpp. If I don't use the ___EXT macro the make_pair works fine. I'm guessing the local state is needed for multithreaded applications or maybe multiple versions of a loadable library?
It is more for doing dynamic linking on systems that don't natively support dynamic linking. But it is also useful for multithreading.
I see the gambit scm to c compiler inserted a function to do the initialization of ___local_gstate in fileio.c but I haven't added anything in fileio_util.cpp to do the same initialization. Am I allowed to call functions like ___make_pair from fileio_util.cpp in the first place? Should I use embedded C code inside the scm file and call __make_pair from there instead?
Thanks
Kartik
Can you try compiling Gambit this way:
./configure CC="gcc -D___CAN_IMPORT_DYNAMICALLY"
and compile your C files with gcc -D___CAN_IMPORT_DYNAMICALLY .
This will activate a definition of ___EXT that does not go through a ___local_gstate variable. Then you can call ___make_pair and friends without errors. Alternatively, don't use ___EXT (it was there to explicitly mark dynamically linked functions so that on platforms with no native dynamic linking the appropriate magic would happen).
Marc