gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: OpenBSD progress


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: OpenBSD progress
Date: 03 May 2004 17:43:59 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and thank you so much for your work on this!

In brief, I've committed what I believe to be equivalents to your
patches in both branches.  Please confirm that gcl compiles out of the
box for you, or let me know what needed changes may remain.

Magnus Henoch <address@hidden> writes:

> Camm Maguire <address@hidden> writes:
> 
> >> * W^X, "write xor exec", seems to cause problems with unexec.  The
> >>   Emacs people haven't solved them, but just disabled it, so I did the
> >>   same.
> >> 
> >
> > How?
> 
> ld -Z, as below.
> 

Great!

> >>   The -Z flag needs to be added to all ld calls, including the one in
> >>   configure where it tries to find the value of DBEGIN.  It is not
> >>   immediately obvious to me how to do that - I would imagine that
> >>   setting LDFLAGS would do it, but LDFLAGS is not mentioned at all in
> >>   configure.in.
> >> 
> >
> > We can also explicitly add in configure.  Is there a relevant test, or
> > is the best just to add when building on openbsd?
> 
> I think just adding it for openbsd is simple and sufficient, which
> I've done in my patch.
> 

OK

> >> There are still some changes in my tree which I haven't verified that
> >> they're really needed.  I'll sort that out in the next few days.
> >> 
> >
> > Perhaps when I get back on wed. I can take a look at your patche and
> > merge if not too difficult for 2.6.2, providing the windows problems
> > are still outstanding by this date.
> 
> Everything applies cleanly to the Version_2_6_1 branch except for the
> patch to main.c, which is trivially adaptable.  The branch compiles,
> and had enough marbles to complete the ANSI tests; I've done more
> tests on the head version.
> 
> 
> 
> configure.in: The second hunk is for dlopen - OpenBSD has it in libc,
> while the current test assumes it is in libdl.  AC_SEARCH_LIBS does
> the equivalent of the commented out part, except that it starts
> checking without any libraries, and that it adds the needed libraries
> to LIBS instead of TLIBS - I don't see how TLIBS would make a
> difference.  As statsysbfd works, but dlopen doesn't (or maybe I just
> don't understand how it works), the hunk can be dropped.
> 

I have dropped this, as several ports do rely on dlopen, and I don't
have time to test right now.  In general, our configure.in logic is
very convoluted and needs cleaning.  I haven't the time at the moment,
alas.  These temporary variables (i.e. TLIBS) were put in at some
point to step around the automatic operation of the autoconf macros
where required.  The whole situation needs revisiting in 2.7.x.

> bsd.h, linux.h: I commented out definitions of HAVE_AOUT, as they only
> confuse things.
> 

OK

> alloc.c: As malloc now checks for recursion, it's OK to use error()
> for allocation error reporting.  There are also some fixes to
> baby_malloc - it's not normally used, but I used it for debugging, so
> I needed it to be in shape.
> 

OK

> main.c: Extend data rlimit, as in alloc.c.
> 

OK

> unexelf.c: Not the same as what I posted the other day, as I
> overlooked a change from Emacs.
> 

I've committed this as it appears to work OK, but do you really need
it?  I thought the main fix here for you was -Z.  In general, I'd
prefer to stay away from partial merges against CVS snapshots unless
required. 

> others: OpenBSD has elf_abi.h instead of elf.h.  Some types and macros
> are different.
> 

OK

> With these modifications, GCL still compiles and runs on Debian/i386
> testing.
> 

Great!  And I confirm on Debian unstable i386.  Will upload a new
Debian package to double check, but I anticipate no difficulties. 

> > Would be nice to know if you can run the ansi-test suite, the
> > random-tester, maxima, acl2 and axiom, as time permits of course.
> 
> The ansi-test suite completes with 1868 out of 16259 total tests
> failed; is that good or bad?  Full output can be found at
> http://w1.312.comhem.se/~u31227643/ansitestoutput.gz .

This is always a moving target given Paul's fine work, but it sounds
in the ballpark.  Stable branch failures are 304 if you'd like to
double check. 

> 
> Maxima 5.9.0 compiles, passes testsuite modulo known bugs, and runs.
> ACL2 works as well.
> 

Great!

> I ran the random-tester for almost 100000 iterations, with
> loop-random-int-forms.  No output except for the progress numbers -
> that's good, right?
> 

Yes!

> That would be all... or did I forget something?
> 

axiom?

Take care,

> Regards,
> Magnus
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.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]