Greetings! Raymond Toy <[EMAIL PROTECTED]> writes:
> I always seem to have a hard time building gcl on any platform but > previously I was always able to eventually muddle through and get a > build done. > My apologies for the difficult configure/make machinery -- I've taken the position that it is more useful to spend time on gcl ansi compliance and compiler performance at this juncture. Eventually hope to clean it up. > But now I can't. In all cases, I just did a simple "configure > --enable-ansi" just to make it build with its defaults. > > On linux, configure finishes and when I try to make, it says it can't > find the dependency on /usr/lib/libbfd.a. (This is Suse 10.3, x86_64.) > GCL has certain build dependencies, a working C compiler and libc development header environment being among them. Conventionally, GCL also requires binutils-dev and libgmp3-dev at build time, but there are local snapshots of these libraries to make do in a pinch. The GMP local build will turn on automatically if no installed GMP is found. The binutils local build must still be invoked by hand thus: --disable-statsysbfd --enable-locbfd Will try to get to automatic behavior at some point. I think it important for GCL however not to fork these libraries for its own use in the long run. Right now, there are GCL-specific bfd patches for alpha, mips, mipsel, and darwin not yet merged into binutils upstream. The list of build dependencies can be found at the head of debian/control > On Mac OS X Leopard (10.5) on x86, it fails when configuring gmp. > Alas, macosx i386 is not yet running, though just requires a little linker attention. macosx ppc is fully functional. In case you are interested in lending a helping hand here, please let me know. > On Solaris 8 (sparc), it configures gmp ok, but then dies trying to c > stack limit. In this case, I think generates the wrong C test code > because it initializes an int with a string or something. > I'd greatly appreciate details here. Please be advised that gclcvs makes good use of immediate fixnums, but that on Debian sparc, at least, the conventional location of the fixnum table is not available, and needs attention. Linux x86 32 reserves memory above 0xc0000000 for the kernel, so GCL uses this area as a immediate fixnum table. Sparc puts the C stack in here. Logic is needed in configure to determine an alternate safe location automatically. Right now, Debian sparc does not have immediate fixnums. A few months ago, I verified that 2.6.8pre built on solaris x86 and sparc. I'd be happy to quickly commit any configure changes you still find are needed here. So more details are the first step. > I can provide more details, if needed. I would just like some hints > on how to do this. > > I also tried gcl 2.6.8. This also fails in more or less the same > ways, but I think 2.6.8 gets a bit farther on sparc. (I did get some > version of 2.6.8_pre to build on solaris long ago.) > Details here also most appreciated. Take care, > Thanks for any hints, > > Ray > > > > _______________________________________________ > Gcl-devel mailing list > Gcl-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/gcl-devel > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
