I don't copy test.o1 to test.o2, but compile the whole module twice, including invoking the Gambit compiler twice. The input to the gambit compiler is identical, the only difference is that I tell it to compile to two different filenames. I double-checked by diffing the .c files and they showed that they are identical except for the link file, which is different on a couple of places where test.oN is mentioned. The error message you get when just moving the file to another spot is not "Unknown error", but an error message where dlsym complains about that the "_____20_test_2e_o2" or whatever the module file name is is not fuond. Which makes sense, but also proves that this problem isn't about that. When I invoke the gambit compiler and GCC, I use ##gambc-cc. At the moment I believe the issue is related to how gambc-cc.bat and ##gambc-cc are designed: They have four different modes of operation: 'obj, 'dyn, 'lib and 'exe. As I understand it, 'exe is for creating a standalone executable. 'lib is unimplemented, but I guess it's intended to create static libraries, 'obj is for compiling .c files to .o files and 'dyn is for creating loadable shared library files. If possible, I would like to be able to compile Scheme to .c (more than one .c file) and then .c to .o and then link the .o to a shared library file in separate steps, but that's not possible to do with ##gambc-cc, because 'obj doesn't send -D___DYNAMIC to the C preprocessor. The problem I got when using compile-to-c, then ##gambc-cc with 'obj, then ##gambc-cc with 'dyn was the same "Unknown error", but it came when loading the shared library file from any gambit instance except for the one that compiled the file. I hacked around that by adding -D___DYNAMIC to cc-options, but now I get "Unknown error" at other times (when loading two similar object files in a row). This makes me believe that the error is because I'm sending the wrong parameters to gcc somewhere, particularly the C compiler part. The test module I use doesn't contain anything suspicious, I think it was a call to pp. And it works when just invoking the shell command "gsc test.scm" twice to get test.o[12]. What I would need is a mode that compiles with the flags that 'dyn does, but that doesn't invoke the linker. But for my purposes right now, I just want to find out what it is that makes it break. I'll look further into this later, my next thing to try is to append "-flat_namespace" to cc-options when invoking ##gambc-cc with 'obj /Per On 8 July 2010 15:26, Marc Feeley <feeley@iro.umontreal.ca> wrote:

The name of the initialization function in a .oN file is derived from the name of the file.  For example, the file test.o2 will contain the initialization function _____20_test_2e_o2 .  The function name is derived from the file name to give it a unique name (i.e. dynamically loaded .oN files will not have conflicting names for the initialization function).  Many OSes don't like dynamically loading files which define the same function, which is why the N in .oN is incremented with each new compilation of a file, giving .oN files and function names that are unique.

Solution: make sure the .oN file name is coherent with the initialization function name (look for #define ___LINKER_ID ...).

... and ... never copy or rename a .oN file (i.e. don't "mv test.o2 test.o1").

Marc

On 2010-07-07, at 12:22 PM, Per Eckerdal wrote:

...

I'm compiling scheme to C, then C to .o then linking, in separate steps. The goal is to create a dynamically loadable object file (one that can be loaded by Gambit's load procedure).

I have this really odd problem: I have two dynamically loadable object files that are identical except for their names (so they are not byte-to-byte identical because the file names are embedded in the files). When I load one of them, it works, but when the other one is loaded, I get "Unknown error". This happens regardless of in which order I load them:

$ gsc Gambit v4.6.0

...

(load "test.o1") "/Users/per/prog/gambit/blackhole/test.o1" (load "test.o2") *** ERROR IN (console)@2.1 -- Unknown error (load "test.o2") 1> *** EOF again to exit

$ gsc Gambit v4.6.0

...

(load "test.o2") "/Users/per/prog/gambit/blackhole/test.o2" (load "test.o1") *** ERROR IN (console)@2.1 -- Unknown error (load "test.o1") 1>

My guess is that I use incorrect compiler and/or linker flags somewhere. I had a similar issue where an object file was only loadable by the same gsc process that created it, which was because I didn't send "-D___DYNAMIC" to the C preprocessor.

The files are compiled using the exact same process, I copy-paste the commands that are used to invoke GCC at the end of the mail. Any pointers?

thanks, /Per

The compilation and linking commands, for the two modules: (this is on OSX)

gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test-rt.o" -D___DYNAMIC  test-rt.c gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test-ct.o" -D___DYNAMIC  test-ct.c gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test-vt.o" -D___DYNAMIC  test-vt.c gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test-mi.o" -D___DYNAMIC  test-mi.c gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test.o1.o" -D___DYNAMIC  test.o1.c gcc    -bundle  -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp   -flat_namespace -undefined suppress  -D___DYNAMIC -I"/usr/local/Gambit-C/include" -o "/Users/per/prog/gambit/blackhole/src/test.o1"     ../../github-modules/work/compile-tmp/1/test.o1.o ../../github-modules/work/compile-tmp/1/test-rt.o ../../github-modules/work/compile-tmp/1/test-ct.o ../../github-modules/work/compile-tmp/1/test-vt.o ../../github-modules/work/compile-tmp/1/test-mi.o

gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test-rt.o" -D___DYNAMIC  test-rt.c gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test-ct.o" -D___DYNAMIC  test-ct.c gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test-vt.o" -D___DYNAMIC  test-vt.c gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test-mi.o" -D___DYNAMIC  test-mi.c gcc    -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp    -I"/usr/local/Gambit-C/include" -c -o "/Users/per/prog/gambit/github-modules/work/compile-tmp/1/test.o2.o" -D___DYNAMIC  test.o2.c gcc    -bundle  -no-cpp-precomp -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp   -flat_namespace -undefined suppress  -D___DYNAMIC -I"/usr/local/Gambit-C/include" -o "/Users/per/prog/gambit/blackhole/src/test.o2"     ../../github-modules/work/compile-tmp/1/test.o2.o ../../github-modules/work/compile-tmp/1/test-rt.o ../../github-modules/work/compile-tmp/1/test-ct.o ../../github-modules/work/compile-tmp/1/test-vt.o ../../github-modules/work/compile-tmp/1/test-mi.o _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

On 2010-7-8, at 19:18 , Per Eckerdal wrote:

I don't copy test.o1 to test.o2, but compile the whole module twice, including invoking the Gambit compiler twice. The input to the gambit compiler is identical, the only difference is that I tell it to compile to two different filenames. I double-checked by diffing the .c files and they showed that they are identical except for the link file, which is different on a couple of places where test.oN is mentioned.

I remember having a similar problem years ago. iirc, there's something written in the c file that forces the name of the o file and it does not obey the compile command. I don't remember if it's direct compile or the 2 step process through a c file though.