Thanks for replying. Contrary to what I said in my previous post,
BFD does exist for Mac OS X. And not only does it exist, but it's
also installed by default, although not made available for external
developers (it's installed as a private "dynamic library"). I've
recompiled it myself with various configure option, but it does
not work yet with GCL (basically, there seems to be memory issues,
I have to sort this out).
Alternatively, I've set up an experimental fasloading mechanism
that uses the Mac OS X counterpart of dlopen. Still working on this
for now. With respect to my current work, I've got the following
questions :
1) What's the logic behind SEEK_TO_END_OFILE ?
2) What is the outcome of build_symbol_table useful for ?
3) What is the expected behavior of faslinking ?
> 1) Do you know about Fink? Is there a gcl currently in Fink?
Yes, I know about Fink. There's no gcl currently in Fink. I thought
of submitting a new package to Fink but I'm not sure this would be
in the spirit of Fink, given that complete portions of code need to
be added (see additional comment on Fink below).
> 2) Would you like to volunteer to maintain this port? We could set
> you up as a gcl developer on savannah.
I'd please contribute to gcl as the maintainer for this port.
> 3) Is there a possibility of setting up an autobuilder for this port
> once it gets rolling? That way binaries can be made available on
> the ftp site. An autobuilder would simply be someone's machine
> connected to the internet with a cron job which would build new
> releases and place them in some publicly accessible place.
How often should the new releases be built ?
> 4) I've committed your three files in CVS head.
> 5) Comments on your patches below.
> -DEFS = -I../h -I../gcl-tk
> +DEFS = -I../h -I../gcl-tk -I/sw/include
> You can accomplish this with the environment variable C_INCLUDE_PATH.
> In any case, too specific to your setup to be committed.
Thanks for the hint. Sure it's to specific to be committed. I'm using
this for my personal convenience. It was just intended as a hint for
people willing to build their own version of GCL on Mac OS X.
> + ranlib $@
> Is this necessary?
I've already encountered this kind of peculiarity as of previous ports.
I happen to think this is necessary in the sense that it will not compile
without it but I'm not an expert. This is typically the kind of issues
that Fink fixes.
> Your 'sed' doesn't take a third argument?
Yes it does, and it even accepts the `1' flag that terminates the
substitution pattern in other contexts but not in this particular
context. Let me look out for this.
> Perhaps it might be better to break the .o files up into a groups
> and loop over the ar rs? What is the max length yours can handle?
I've tried this, but it does not seem an acceptable solution.
> Not sure we should depend on libtool. Could make a configure
> option, but these are already crowded.
Note that Apple's libtool has nothing to do with GNU libtool. Apple's
libtool is meant as a replacement tool for ar and ranlib (at least, it
copes with some limitations of ar that are specific to Mac OS X).