gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: Building gcl from cvs?


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: Building gcl from cvs?
Date: 11 Jan 2008 19:21:27 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Raymond Toy <address@hidden> writes:

> Camm Maguire wrote:
> > Greetings!
> > Raymond Toy <address@hidden> writes:
> >
> >> Camm Maguire wrote:
> >>> 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
> >> Ah, this really helps a lot on solaris/sparc for
> >> gcl2.6.8pre. Configure finishes, and it builds just about everything.
> >> The only issue is that I don't have a working pdflatex, so the build
> >> never finishes making saved_gcl.  If I comment out the parts about
> >> building dwdoc.pdf, everything finishes and saved_ansi_gcl is created.
> >>
> >> Unfortunately, cvs gcl still doesn't configure correctly.  First,
> >> configure near line 4942 has this:
> >>
> >>       if ! test -x `which ldd` ; then
> >>
> >> I think it really should be:
> >>
> >>       if test ! -x `which ldd` ; then
> >>
> > Odd, I thought the former was the standard shell syntax.  I'll see if
> > bash groks the latter.
> 
> Umm, configure starts with #!/bin/sh. :-)
> 

Indeed :-)

> One other issue.  Solaris's tail doesn't grok -n.  Instead of tail -n
> 1, tail -1 works.
> 

OK will post when this is in.

> >
> >> Configure still fails because it can't determine the C stack.  Can I
> >> set heap_ceiling = 0 for solaris/sparc is it is for solaris-i386?  If
> >> I do that, configure finishes.  I'm doing the build right now.  It
> >> will take quite a while before I know the outcome....
> >>
> > This should be fine given that sparc puts shared libs way up around
> > 0xf0000000 AFAIR.  The configure logic at present really is a quite
> 
> The C stack starts at 0xffbf0000 (Ultrasparcs, Solaris 7+).  The
> shared libs start below the stack, but will go wherever there is space
> for them.  .text starts at 0x01000000, I think.
> 
> > I'd be interested in seing the failed configure log, presuming that
> > ldd was corectly found.  Trouble here is, I bet the output thereof,
> > which configure attempts to parse, is anything but standard.  Perhaps
> 
> Oh, right.  I did see that it found ldd correctly.  I also noticed
> that on Linux ldd puts information out about where the shared lib
> goes. Solaris's ldd doesn't produce any addresses.  However pmap <pid>
> will give you that information.  A quick look at various processes
> indicates that the location of libc is in a different place.
> 
> If you really want config.log, I can provide that to you.
> 
> > also ldd configure would help.
> 
> ldd configure?  What do you mean?
> 

This is no longer necessary given the absense of addresses output.  we
could put in a little code to check the /proc filesystem, which is
what I assume pmap does, but there is another fly in the ointment.
Ironically, this memory layout is the "best" in many respects, but our
current logic was adapted to the traditional *very* difficult shared
mem location on x86 Linux at 0x40000000, right in the middle.  Here,
this address is not fixed, and indeed will change as the stack is
enlarged, via ulimit or even GCL itself via setrlimit.  Plus, given
that cvs can load new shared libs on the fly, the floor of this space
can decrease at runtime (presumably).  So what is the best way to
ensure that the shared libs remain above a certain address (for the
imm fix table)?  It is possible that the logic in GCL would allow
overlap of the immfix table with the shared lib space, but definitely
not the C stack space -- the latter can of course be adjusted -- but I
have not verified this yet.

We could of course just abandon automatic configuration here and
provide configure switches for the expert user to control things.

Sparc expert advice most appreciated.

Take care,

> Ray
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]