On Sun, Apr 20, 2008 at 11:41 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > > > On Apr 21, 7:33 am, mabshoff <[EMAIL PROTECTED] > > > dortmund.de> wrote: > > On Apr 21, 6:48 am, "Bill Page" <[EMAIL PROTECTED]> wrote: > > > > > On Sun, Apr 20, 2008 at 7:22 PM, mabshoff wrote: > > <SNIP> > > > > > GCL uses the C compiler directly. I am not suggesting that GCL is > > > necessarily the "right" lisp for Sage (or even that Sage needs a lisp > > > compiler at all) but I do rather think you should give GCL another > > > try. I would be glad to try to help you debug the problems on Solaris. > > > > In both cases the current CVS checkout out from savannah blows up on > > Solaris 9 and 10 in the same spot: > > > > Solaris 9: > > > > # Subconfigure of BFD done > > # ------------------------ > > # > > checking size of long... 4 > > checking size of int... 4 > > checking size of short... 2 > > checking size of char... 1 > > checking for number of bits in char... 8 > > checking whether byte ordering is bigendian... yes > > checking for sbrk... yes > > checking for randomized sbrk... no > > checking for required object alignment... 8 > > checking for C extension variable alignment... __attribute__ ((aligned > > (8))) > > checking TYPE_BITS macro... 0xff09 > > checking sizeof struct contblock... 8 > > checking for pagewidth... 13 > > checking DBEGIN... 0x20000 > > checking CSTACK_ADDRESS... 0xffbfffff > > checking NEG_CSTACK_ADDRESS... yes > > checking finding CSTACK_ALIGNMENT... 8 > > checking CSTACK_DIRECTION... -1 > > checking for shared library/C stack ceiling to heap... failed > > > > Solaris 10: > > > > # > > # Subconfigure of BFD done > > # ------------------------ > > # > > checking size of long... 4 > > checking size of int... 4 > > checking size of short... 2 > > checking size of char... 1 > > checking for number of bits in char... 8 > > checking whether byte ordering is bigendian... yes > > checking for sbrk... yes > > checking for randomized sbrk... no > > checking for required object alignment... 8 > > checking for C extension variable alignment... __attribute__ ((aligned > > (8))) > > checking TYPE_BITS macro... 0xff09 > > checking sizeof struct contblock... 8 > > checking for pagewidth... 13 > > checking DBEGIN... 0x20000 > > checking CSTACK_ADDRESS... 0xffbfffff > > checking NEG_CSTACK_ADDRESS... yes > > checking finding CSTACK_ALIGNMENT... 8 > > checking CSTACK_DIRECTION... -1 > > checking for shared library/C stack ceiling to heap... ./configure: !: > > not found > > usage: tail [+/-[n][lbc][f]] [file] > > tail [+/-[n][l][r|f]] [file] > > failed > > > > This second failure leaves me to believe that someone is assuming a > > version of GNU tail. I am using a gcc 4.2.2 compiled from sources both > > times. > > But thinking about the above issue I do not believe that it is > actually the root cause. > > And some more build tests: > > 3) OSX 10.5.2 Intel, current XCode 3.0: > > bsd:gcl mabshoff$ uname -a > Darwin bsd.local 9.2.0 Darwin Kernel Version 9.2.0: Tue Feb 5 > 16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386 i386 > > checking how to switch to text section... .text > checking how to switch to data section... .data > checking what assembly label suffix to use... : > checking how to export a symbol... .globl > checking if globals are prefixed by underscore... configure: error: > Test program links neither with nor without underscore. > # > # > # > # Subconfigure of GMP done > # ------------------------ > # > cp: gmp3/gmp.h: No such file or directory > checking for leading underscore in object symbols... yes > checking for GNU ld option -Map... no > checking for size of gmp limbs... Cannot determine mpsize > > 4) And the most ironic build failure on an x86-64 Debian box: > > [EMAIL PROTECTED]:~/gcl$ uname -a > Linux sage 2.6.18-6-amd64 #1 SMP Sun Feb 10 17:50:19 UTC 2008 x86_64 > GNU/Linux > [EMAIL PROTECTED]:~/gcl$ make > make: *** No rule to make target `/usr/lib/libbfd.a', needed by > `copy_bfd'. Stop. > > I have hit the same bug months ago with RHEL 4 x86-64, so I am not > being the unluckiest person on the planet and check out cvs on the > wrong day. > > On a positive note it build fine on RHEL 5/Itanium. > > So, in the end I only hope that you can understand why I am more than > a little dubious about the build quality of gcl. All these are boxen > that build Sage fine [the Solaris boxen need a little help, i.e. about > 2,3 fixes, but all that is getting merged back into Sage 3.0.1 or > 3.0.2], so this is far from some FUBAR build box where I set gcl up to > fail. >
In the defense of GCL, *most* components of Sage were a mess like above when I/you/whoever first tried to add them to Sage. I personally haven't tried much using cvs GCL only, partly because it scares me to use cvs for a deployed quality product. Since cvs might be broken one day, not the next, etc., and one has no clue if the code has been tested or not or what. The last released version is from 2005, and it's clear the website is just dead (maybe somebody lost the password?!) I mean, it just looks a little silly for the website (http://www.gnu.org/software/gcl/) to start with: NEW! (20050810) GCL 2.6.7 is released. The release notes can be found here. NEW! (20050427) Patch added to the errata page to reenable support for si::run-process on linux. NEW! (20050402) Support for new texinfo format and precompiled regexp searching posted to errata page. The GCL-devel mailing list has on average about 5-6 messages a month during the last couple of months, except for a bunch of messages in January about people trying to build GCL from cvs. I've made a gcl Sage optional spkg: http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg It's just GCL-from-cvs + a simple spkg-install. I have never got it to build on any system. It's a pretty big spkg, since it appears to include the entire gas assembler, some version of GMP, etc. Try it out and see if it *doesn't* work for you too :-) wget http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg sage -i gcl-20080421.spkg Bill Page -- I would be interested in any comments you might have. For example, is the fact that GCL doesn't build for us anywhere, something that you think we'll get passed by just trying harder? Or is it going to be really really hard. -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
