[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
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
Public key: http://pgp.mit.edu
More information about the Gambit-list