[gambit-list] Illegal character

Joel J. Adamson adamsonj at email.unc.edu
Tue Jul 1 13:48:33 EDT 2008

Bradley Lucier <lucier at math.purdue.edu> writes:

> On Jun 30, 2008, at 4:08 PM, Joel J. Adamson wrote:
>> Did you notice anything else amiss with my compilation commands?
> If you just want to make a dynamically loadable library, it seems
> somewhat perverse to ignore the built-in support for building
> dynamically loadable libraries in gsc and not to define a file
> "all.scm" that contains simply
> (include "file1.scm")
> (include "file2.scm")
> ...
> and then
> % gsc
>> (compile-file "all")
>> (load "all")
> unless you have a special reason (i.e., you need to link an external
> library).

I'm using the GNU Scientific Library: there's actually quite a bit of
foreign code in these modules.

Your approach makes a lot of sense, but the files I'm compiling are
"headers" that include the conceptually linked parts of the program: all
the gsl-interfacing code is (include)d in "gsl_genx.scm," all the srfis
are in "srfi.scm" and so on.

> And if you're using gcc your CCOPTS (a) don't include " -fwrapv -fno-
> strict-aliasing", which are needed for correctness and (b) have no
> optimization options ("-O1" and a few others are best, not -O2 or - 
> O3) and no -D___SINGLE_HOST.

Hmmm...good to know.  I thought those would only be needed (because I
haven't studied gcc enough!) when I was compiling an executable ;)

> I've seen a number of posts to this mail list where people don't want
> to use this built-in machinery for building dynamically loadable
> files, but I don't understand why.

Would it be practical to just compile the foreign-interfacing files with
gcc and use compile-file with the rest of them?


Joel J. Adamson
(303) 880-3109
Public key: http://pgp.mit.edu

More information about the Gambit-list mailing list