For the benefit of the readers of this list, I am copying my reply to a question on comp.lang.scheme.
Marc
On Dec 12, 4:55 pm, Eduardo Costa <edu50...(a)gmail.com> wrote:
- Hide quoted text -
> I have posted similar questions in the comp.lang.lisp list, but I
> would like to know the opinion of the Scheme community as well. I am
> writing dynamic web pages in commercial hosting services. Most hosting
> services won't let me install my own server, or libraries. Therefore,
> I am forced into CGI.
> Right now, the programs are working in Stalin. Scheme code includes a
> lot of text processing stuff, like Dorai Sitaram's pregexpr, htmltags,
> etc. Even so, Stalin has a very small footprint (219 kbytes). There
> is no question that Stalin is linking to dynamic libraries. On the
> other hand, Bigloo and Gambit code require static linking. The
> command line to compile with Stalin is given below:
> $ stalin -On -t cross.sc -copt -O3
> The gambit command line takes the form:
> $ gsc-script -exe -o gambit.cgi gambtest.scm
> The gambit program is one order of magnitute larger than the Stalin
> application. What is worse, the gambit program does not work. When I
> try to call gambit.cgi from the web, I get:
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
> My first guess is that I need to compile the program with static C
> libraries. Therefore, I modified the command line thus:
> $ gsc-script -exe -ld-options -static gambtest.scm
> collect2: ld returned 1 exit status
> *** ERROR IN ##main -- C link failed while linking "/home/lisp/gambc-
> v4_6_2-devel/gsc/gambtest.o" "/home/lisp/gambc-v4_6_2-devel/gsc/
> gambtest_.o"
> lisp@LispMachine:~/gambc-v4_6_2-devel/gsc$ gsc-script -exe -ld-options
> -static gambtest.scm
> Why Stalin linked to dynamic libraries works everywhere, but Gambit
> does not? How to fix the Gambit program?
First of all it is possible to dynamically link the Gambit-C runtime.
When you run the configure script, add the --enable-shared command
line option. Static linking is the default because on most desktops
it isn't a big issue to copy the runtime system to each program (it is
about 5 MB), and it avoids problems with setting up the correct path
for loading dynamic libraries. A hello-world program is a few KB when
using a dynamically linked Gambit runtime.
Moreover, have you considered running your CGI scripts as Scheme
scripts? Then the size of your script is really just the size of your
source code. This can be achieved by starting the first line of your
CGI script like this:
#! /usr/bin/gsi-script
(display "hello world!\n")
Adjust the path if Gambit is not installed at the usual place.
Now back to the problem you are encountering. It is probably due to a
misuse of the controlling terminal. By default, REPL interaction goes
to the controlling TTY of the process (this includes output that is
generated with the pp procedure, or any tracing, warning and error
messages). This is probably not what you want for a CGI script. You
can redirect the interaction channel to the standard input/output by
adding the flag -:d- when the program is launched. This can also be
achieved by adding that option to the first line of your script, i.e.:
#! /usr/bin/gsi-script -:d-
(display "hello world!\n")
This will work whether the script is interpreted, or compiled. For
example, if the above script is called foo.scm, you can compile it to
foo.cgi with the command
gsc -exe foo.cgi foo.scm
If your problems persist or if you have other questions, please direct
them to the Gambit mailing list.
Marc