Hi Camm.
| Brilliant! I try this, and get the following autoconf warning:
|
| configure.in:959: warning: AC_TRY_RUN called without default
| to allow cross compiling
|
| though it appears to work ok. Ideas? AC_C_BIGENDIAN appears
| to be defined in terms of AC_TRY_RUN, which will give this
| warning unless cross-compiling defaults are provided, but
| there appears to be no way to get to the latter via the
| former. cf. other AC_TRY_RUN definitions in our configure.in.
My newly acquired PDF autoconf manual says this about AC_TRY_RUN in the
"Obsolete Constructs" chapter:
"AC TRY RUN (program, [action-if-true], [action-if-false], [Macro]
[action-if-cross-compiling])
Same as ‘AC_RUN_IFELSE([AC_LANG_SOURCE([[program]], [action-if-true],
[action-if-false], [action-if-cross-compiling])’ (see Section 6.6 [Run
Time], page 78)."
I think it's a bit odd that this macro should be obsolete but still in use to
define approved macros (of which AC_C_BIGENDIAN is an example).
Doubly so as in Chapter 15 the manual goes on to say:
"Since Autoconf 2.50, internal codes uses AC_PREPROC_IFELSE, AC_COMPILE_IFELSE,
AC_LINK_IFELSE, and AC_RUN_IFELSE on one hand and AC_LANG_SOURCES, and
AC_LANG_PROGRAM on the other hand instead of the deprecated AC_TRY_CPP,
AC_TRY_COMPILE, AC_TRY_LINK, and AC_TRY_RUN. The motivations where:
− a more consistent interface: AC_TRY_COMPILE etc. were double quoting their
arguments;
− the combinatoric explosion is solved by decomposing on the one hand the
generation of sources, and on the other hand executing the program;
− this scheme helps supporting more languages than plain C and C++.
In addition to the change of syntax, the philosphy has changed too: while
emphasis was put on speed at the expense of accuracy, today’s Autoconf promotes
accuracy of the testing framework at, ahem..., the expense of speed."
My autoconf is 2.56.
| > Slightly more radically, we could remove the LITTLE_END
| macro entirely and substitute the automatically generated
| WORDS_BIGENDIAN macro in our HEAD source code.
| >
| > We could also clean out all other non-standard endian
| references in configure.in and gclincl.h.
| >
|
| OK, did a first pass at this now in CVS head.
Thanks. It worked here.
| (LITTLE_END). So in sum 2.6.8 on mingw can only suffer here
| re: compiling clx, AFAICT.
Which is, of course, irrelevant to Windows.
| On the other hand, it will be
| some time before I am convinced that this new macro is
| working across all the *ixs. In particular, a lot of work
| went into this re: the arm port used by hand-helds. Perhaps
| we should defer judgement until I upload another gclcvs into Debian.
Good idea.
| The issue here AFAICT is that your NULL_OR_ON_C_STACK macro
| is not aborting the recursion into this imm fix address. We
| need to rename the macro,
I vote that we do this (and other obvious cleanups) before 2.7.0 goes out the
door. Might as well do them now so that I get Windows working in the context
of a meaningful and stable set of names and definitions.
| but conceptually, it refers to
| addresses permanently outside the heap, so should be true on
| imm fixnums too.
OK, I've modified NULL_OR_ON_C_STACK to:
#define NULL_OR_ON_C_STACK(y) \
(((unsigned long) (y)) <= cs_org ||
((unsigned long) (y)) > (unsigned long) core_end)
Which seems to work. I'm unravelling other new issues now to do with the
Windows shared memory in "o/mingwin.c", but I'm hoping that you've sorted out
the problem which has held me up since June, thanks.
Cheers
Mike Thomas.
_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
