Bradley Lucier lucier@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?
Thanks, Joel