On 2011-12-14, at 1:08 AM, Eduardo Costa wrote:

Hi, Marc.

I still cannot understand what is going on. When I compile for Bigloo, I get the same error if I compile with the following options:

bigloo -static-bigloo whatever.scm -o whatever.cgi

However, if I pass the static option to the gcc compiler, everything works well.

bigloo -static-bigloo -copt -static whatever.scm -o whatever.cgi

I cannot see why Gambit cannot have the same options. I mean, an all static linking. BTW, I tried to pass the static option to gcc through cc-options, but I get an error.

It is possible to statically link the C runtime by specifying this to the "configure" script. For example:

% make clean % CC="gcc -static" ./configure --enable-single-host % make % strip gsi/gsi % ls -lh gsi/gsi -rwxr-x--- 1 feeley parallelisme 4.8M 2011-12-14 09:18 gsi/gsi % ldd gsi/gsi not a dynamic executable

% make clean % CC="gcc" ./configure --enable-single-host % make % strip gsi/gsi % ls -lh gsi/gsi -rwxr-x--- 1 feeley parallelisme 4.5M 2011-12-14 09:20 gsi/gsi % ldd gsi/gsi linux-vdso.so.1 => (0x00007fff96d70000) libutil.so.1 => /lib64/libutil.so.1 (0x0000003f6fe00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003f62600000) libm.so.6 => /lib64/libm.so.6 (0x0000003f62200000) libc.so.6 => /lib64/libc.so.6 (0x0000003f61e00000) /lib64/ld-linux-x86-64.so.2 (0x0000003f60c00000)

[Note that for some reason I don't understand, I had to remove the -mieee-fp flag detection logic from the configure script because that was causing a multiple symbol definition at link time on the Linux machine I tried this on.]

I have a completely unrelated question. I noticed that Gambit has a much smaller compiler than SBCL.

Depends. On my Mac OS X machine, the Gambit compiler (stripped) is 5.5 MB and the sbcl compiler's sbcl.core file is 41 MB. Don't forget however that the Gambit-C compiler relies on the presence of a C compiler (typically gcc) which also takes quite a bit of space, probably many times more that sbcl.core when you include precompiled libraries and header files. On the other hand it allows you to mix Scheme and C code and easily interface with foreign code.

Do you think that this could be a great advantage for scripting? I mean, since Gambit has a smaller compiler, it would have a faster start-up. Does it make sense?

If you only care about using the interpreter (which would make sense for scripting), then Gambit will be advantageous. Gambit does have a fast startup. On my Mac OS X machine which has a SSD, it takes 7 ms to start gsi, and 13 ms to start gsc. So using gsi or gsc for scripting is efficient. Note that on the same machine, sbcl starts up about as quickly as gsc (14 ms).

Marc

--- On Tue, 12/13/11, Marc Feeley feeley@iro.umontreal.ca wrote:

From: Marc Feeley feeley@iro.umontreal.ca Subject: Re: [gambit-list] cgi in Gambit To: "Eduardo Costa" edu500ac@yahoo.com Date: Tuesday, December 13, 2011, 4:14 PM

On 2011-12-13, at 4:35 PM, Eduardo Costa wrote:

...

Well, people at hostgator, believe me or not, don't know what a path is... They use something called fakepath. In any case, I created a page so you can make the tests you feel fit. In order to enter that page, type:

I tested your setup quickly and found that you linked Gambit with GLIBC 2.11, but only GLIBC 2.5 is installed. The message I get when executing gsi is

./gsi: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./gsi)

You can get this information by visiting the page:

http://advogadosmg.org/cgi-bin/env.cgi

You might want to change the script env.cgi to poke around the server to see how it is configured.

I suggest you recompile Gambit on a system which has GLIBC 2.5 . That should solve your problem.

Marc