gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Building GCL from CVS on Ubuntu 12.04


From: Camm Maguire
Subject: Re: [Gcl-devel] Building GCL from CVS on Ubuntu 12.04
Date: Wed, 23 Jan 2013 11:33:47 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Greetings!

Raymond Toy <address@hidden> writes:

>>>>>> "Camm" == Camm Maguire <address@hidden> writes:
>
>     Camm> Greetings, and thanks!  Here is the version from experimental, which
>     Camm> (hopefully) will shortly be cvs head:
>
>     Camm>    heap_ceiling=0x`/bin/cat /proc/self/maps | egrep 
> "/lib/([[^/]]*/)?ld"
>     Camm>    | cut -f1 -d- | head -1`
>
>     Camm> This will vary slightly from run to run.  We just use a truncated
>     Camm> (floor) value as ceiling to the growth of the heap.  So exact
>     Camm> reproducibility is not a problem.
>
> I tried to get gcl to build on Solaris sparc, but gave up at this
> point.  (It used to be the only system where I could somewhat reliably
> build gcl, but now I can't build it anywhere, including linux.)
>

I haven't updated cvs head recently as I've been trying to solidify the
experimental branch, which I hope to make the default soon.  There are a
few minor bit rot issues such as the one posted by the original
submitter, but it should work without too much trouble.  

I've lost access to any solaris machine.  Thus support here is the most
problematic going forward.  If you can provide access, I'll keep it in
the loop.  I've just committed a default timezone patch for example
which has a vacuous default on solaris.

> Why do you need a heap ceiling?  How would I find out a value for
> Solaris/sparc?

gcl uses the sbrk system call to grow memory contiguously from the end
of the .data section of the executable.  Various systems load shared
libraries at some arbitrary (but 'basically' fixed) address above this
point.  Alas, I have seen sbrk not fail as this region is overrun.
Worse, some system calls (e.g. getpwnam, or some such) will dlopen
shared libraries even when compiled statically.  So gcl needs to know
where this region is to stay away from it.  /proc/pid/maps or equivalent
should have it for you.  Or we could put in a configure test to do an
explicit dlopen and generate a floor from the symbol addresses.

Take care,

>
> Ray
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> https://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]