On 2012-02-03, at 3:50 AM, REPLeffect wrote:
I finally tried actually building the contents of the tar file (silly me, I should have done that right away).
Here are the results I got:
$ make gsc -c -o f1a.c f1a.scm gsc -obj -o f1a.o f1a.c gcc -c -o f1b.o f1b.c gsc -link -flat -o f1_.c f1a.c f1b.c *** WARNING -- "display" is not defined, *** referenced in: ("f1a.c") gsc -obj -o f1_.o -cc-options "-D___LIBRARY" f1_.c ar -rc f1.a f1a.o f1b.o f1_.o gsc -c -o f2a.c f2a.scm gsc -obj -o f2a.o f2a.c gcc -c -o f2b.o f2b.c gsc -link -flat -o f2_.c f2a.c f2b.c *** WARNING -- "display" is not defined, *** referenced in: ("f2a.c") gsc -obj -o f2_.o -cc-options "-D___LIBRARY" f2_.c ar -rc f2.a f2a.o f2b.o f2_.o gsc -c -o f3.c f3.scm gsc -obj -o f3.o f3.c gsc -link -o f3_.c f1_.c f2_.c f3.c gsc -obj -o f3_.o f3_.c gsc -exe -o f3.exe -ld-options "f1.a f2.a" f3_.o f3.o f1.a(f1a.o): In function `___H__20_f1a(___processor_state_struct*)': f1a.c:(.text+0x126): undefined reference to `f1b_hello()' f2.a(f2a.o): In function `___H__20_f2a(___processor_state_struct*)': f2a.c:(.text+0x126): undefined reference to `f2b_hello()' collect2: ld returned 1 exit status *** ERROR IN ##main -- C link failed while linking "f3_.o" "f3.o" make: *** [f3.exe] Error 70
I suspected this was due to the fact that I am using Gambit 4.6.3 compiled with --enable-cplusplus. Sure enough, I compiled another copy without the -enable-cplusplus option, and the code above compiles fine on it.
Then I finally woke up from my stupor, and changed the call to "gcc" on line 7 of the makefile to "g++".
I should have thought of that when writing the makefile. The rule .c.o in the makefile can be improved to use "gsc -obj" instead of "gcc -c" (or "g++ -c"). That way, the C compiler which was configured with the system will be used indirectly through a call to gsc, and there are no longer any dependencies on the specific setup of the target platform. In other words the makefile itself is very portable. The only portability issues left are the file extensions (for example Unix and MinGW use .o and .a and Microsoft Visual C++ uses .obj and .lib) and the program to create libraries ("ar" on Unix and MinGW and "link" on Microsoft Visual C++). These issues could be resolved by using the gambc-cc shell script which has this knowledge. For example, on Mac OS X
% gambc-cc LIB_EXTENSION .a
But accounting for this in the makefile to make it totally portable might make it very hard to understand. So I'm not sure what's best here, portability or maintainability.
Marc
P.S. Here is the improved makefile:
.SUFFIXES: .SUFFIXES: .o .c .scm .exe
all: f3.exe
.c.o: gsc -obj -o $@ $*.c
.scm.o: gsc -c -o $*.c $*.scm gsc -obj -o $@ $*.c
f1_.o: f1a.o f1b.o gsc -link -flat -o $*.c f1a.c f1b.c gsc -obj -o $@ -cc-options "-D___LIBRARY" $*.c
f2_.o: f2a.o f2b.o gsc -link -flat -o $*.c f2a.c f2b.c gsc -obj -o $@ -cc-options "-D___LIBRARY" $*.c
f1.a: f1a.o f1b.o f1_.o ar -rc $@ $^
f2.a: f2a.o f2b.o f2_.o ar -rc $@ $^
f3.exe: f1.a f2.a f3.o gsc -link -o f3_.c f1_.c f2_.c f3.c gsc -obj -o f3_.o f3_.c gsc -exe -o $@ -ld-options "f1.a f2.a" f3_.o f3.o
clean: rm -f f1a.c f1_.c f2a.c f2_.c f3.c f3_.c *.o *.exe *.a *~