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.
> > Regards,
> > Bill Page.
>
> Cheers,
>
> Michael
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
