RE: [Gcl-devel] HEAD and GBC on Windows.

[Mike Thomas]

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.