Were it only that simple. Typically, many, many failures are required to get a working build on a lesser known machine. gcl/axiom flushes out instabilities in gcc, binutils, and several other very low-level parts of the toolchain. That said, getting all the builds working flushes out bugs in gcl too.
At least the bugs in the toolchain are discovered.
Witness the issues at present: gcl switch statements apparently generate bogus jump table assembler on mips, gcc-object-inserted symbols __divq/__remq on alpha are apparently uwrappable (*), new GPREL_32 relocs in the new .rodata section needed support on alpha, new GNU_HASH section types required binutils patches, etc. (*) As you know, GCL loads object (.o) files into a running image, which can then be dumped and executed later. It therefore needs the ability to relocate all symbols in the .o file. Relocating to addresses in external shared libraries is dangerous, as the lib may not be in the same place on image restart. 2.6.x had a plt mechanism, which attempted to force gcc to provide local addresses by compiling in functions using the addresses of the external functions. This broke with subsequenct gcc developements, so even with the plt, relocations were being set to shared library addresses on some machines. Now, 2.7.0 redirects all such calls through a pointer in the C source which is reset on image startup. __divq and the like, alas, have no representative in the C source, and cannot be handled thus. Ideally, we can define a wrapper function and relocate to that, but this procedure has been problematic with mcount (for example) on s390 and ppc. (just a taste ... :-)
So the problem is actually in GCL, that it is still not stable enough to do some serious work on top of it? I am just surprised, how many problems there are just with compiling. I myself use Python/C/C++/Fortran and never had experienced any problems like that. So maybe the lisp is not a mature platform for larger projects? My naive opinion is that one should try to stick to ways of doing programs that everyone does, so that such low-level bugs are already fixed. Ondrej _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
