[Gcl-devel] Re: OpenBSD progress

[Magnus Henoch]

Camm Maguire <address@hidden> writes:

> 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.

-Z must be in LDFLAGS for the DBEGIN configure test.  Something like
this:

--- orig/configure.in
+++ mod/configure.in
@@ -994,6 +994,8 @@
 fi
 
 
+old_LDFLAGS="$LDFLAGS"
+LDFLAGS="$TLDFLAGS"
 AC_MSG_CHECKING("finding DBEGIN")
 AC_TRY_RUN([#include <stdio.h>
             #include <stdlib.h>
@@ -1035,6 +1037,7 @@
 /* where data begins */
 )
 AC_MSG_RESULT(got $dbegin)
+LDFLAGS="$old_LDFLAGS"
 
 
 AC_MSG_CHECKING("finding CSTACK_ADDRESS")

Except for that, it works fine.

[...]

> 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.

That would be an interesting thing to work on.  Right now, I don't
have time, however.

>> 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. 

Indeed.  I tried the previous version of unexelf.c, and it works as
well; -Z was what made it work.

[...]

> axiom?

It fails to build for reasons unrelated to GCL - needs GNU make but
explicitly calls `make', doesn't find X headers, etc.

Regards,
Magnus