Camm Maguire <[EMAIL PROTECTED]> writes: > OK, preliminary equalp hashing is in CVS head. Are you comfortable > compiling from there, or do you prefer to wait for Debian package > migration. I still have a few other items that need going in before I > tag t6 and make another Debian upload.
I tried compiling from CVS but some libraries are apparently missing: gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer -I/home/neuss/CL-HOME/gcl/o -I../h -I../gcl-tk fat_string.c fat_string.c:17:17: bfd.h: No such file or directory fat_string.c:18:21: bfdlink.h: No such file or directory ... I guess I should wait for the Debian package. > ... > Thank you for this. This is indeed a reproducible bug. It will > require a radical change which I'm hesitatnt to attempt at this > moment. Basically, GCL writes an initialization lisp code sequence > at the end of each compiled file. It reads the code, loads the > object, identifies the objects in the code with their addresses in the > loaded binary, then evaluates the forms. What it needs to do is read > one form at a time, identify, and eval, etc. You make and use the > package in the same initialization sequence. A standard workaround is > to put all your defpackage statements in a separate file which is > loaded first. Is this doable for you? Hmm, I actually like this self-contained setup for small packages. Therefore I want to leave it as it is. Testing Femlisp/GCL should work anyway (maybe slightly more uncomfortably), only reloading binaries into a fresh GCL would not work. > We will eventually get to this, but it would appear that other > priorities are more pressing at the moment. Please let me know how > this might impact your work -- that is how the pririties are set in > the first place :-). The Femlisp port to GCL is not very high-priority for me, although it would be nice to have it working. I will try out new GCL features as they arrive and report to this list at which point the port hangs. I guess that this is the most fruitful approach for both parties. Yours, Nicolas. _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
