> 1) Do you have access to a publicly accesible ftp directory which I
> may poll in the webpage autoupdate script? If you upload files
> with, say, the name gcl_.*_macosx.tar.gz there, where .* is a
> version string, the script will install the latest built binary
> tarball on the website.
No, I don't have access to any publicly accessible ftp directory.
However, if the script can handle password protected ftp access, I
can occasionally run an ftp server on my own machine and wait for
the script to retrieve the archive.
> I think there is a small confusion -- you've been using cust-reloc
> thus far, and this method, as well as the bfd method, do not use the
> external ld (or ld.so). Only images using dlopen *must* build maxima,
> acl2, and axiom via the external ld (e.g. the alternate maxima gcl
> link, the compiler::link patches I've posted to the axiom list
> recently under the section labeled '2)'). Other images *can* use the
> external ld linking method if they prefer, but *native* relocation and
> image saving with a simple call to save-system works as well and is
> generally preferred. You might want to look at the longish post I
> submitted recently to the axiom list.
Strictly speaking, what I was doing thus far was more akin to dlopen'ing
than to cust-reloc'ating. This was not cust-reloc'ating as there was no
custom relocation whatsoever (thus far). And this was not really dlopen'ing
either as I was not using the functions declared in dlfcn.h. Instead, I was
using Mac OS X's own functions to achieve the result that the functions in
dlfcn.h allow you to achieve elsewhere ; as such, I had no other solution
than to use the external linker to transform raw compiler output files into
shared object files suitable for dynamic loading, whatever the situation.
What's confusing is why I was using the cust-reloc configure flag instead of
the dlopen one. This is because the cust-reloc flag didn't cause the configure
script to look for anything particular, whereas the dlopen flag caused the
configure script to look for unnecessary stuff. Now, however, this is real
custom relocation, so the use of the corresponding cust-reloc flag should no
longer be misleading. I hope this clarifies a bit.
> 4) Is your latest posted patch list the latest? I'd like to merge in
> any changes you've needed.
It's almost up-to-date. You cannot merge the changes I made to
"unixport/makefile" because there are too specific but there should be
no problem merging the changes to "o/main.c" and "o/unixfasl.c".
> 5) Is your bfd linking working though a patch to the GCL bfd tree,
> i.e. you use locbfd? If so, perhaps we could convince BFD upstream
> to apply it?
This is not yet integrated into the local GCL bfd tree, but I'm planning
to do it shortly.