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

[Camm Maguire]

Greetings!

Raymond Toy <address@hidden> 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
> 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