configure cannot test when cross-compiling should be ok

[The Senator]

Greetings folks,

Thanks for a great piece of software!

I am building guile using the guile-1.8.0 tarball downloaded from the
frontpage of gnu.org/software/guile. I have successfully used the
tarball to compile  guile-1.8.0 to run on Linux, but couldn't get it
(cross-compile) to run on windows. I am using

i586-mingw32msvc-gcc (GCC) 3.4.2 (mingw-special)

as my cross-compiler. My first problem is:
./configure gets stuck with the following message.

checking for restartable system calls... configure: error: cannot run
test program while cross compiling

Trawling on the Internet, I found the following suggestion, and
reproduce an excerpt here for completeness. Full post at
http://curl.haxx.se/mail/lib-2003-05/0014.html


 In order to get cross-compile to work, the exit(1) code needs to
 be removed from the ./configure script when checking for writeable
 argv.

Thanks for catching this, Ben.

It turns out the AC_TRY_RUN() macro was not being used properly in
the configure.ac script. I've now patched it to instead use
AC_RUN_IFELSE() and when cross-compiling, the option will default to
'no' and also output a warning about this being a default and not
actually checked for.


So I have followed the suggestion (to remove the exit calls) for now,
and deleted the exit codes, so that no testing is done since this is
meaningless. Refer to patch below. Of course, it should be
configure.in that gets patched, but I am still reading through that,
so I'm not confident enough to do that myself. I am not too sure about
this fix even, but hopefully, someone can pick this up and run with
it.

--- configure-old-with-errors   2006-05-13 20:19:06.0 +1200
+++ configure   2006-05-15 02:44:35.0 +1200
@@ -37596,7 +37596,7 @@
See \`config.log' for more details. 5
echo $as_me: error: cannot run test program while cross compiling
See \`config.log' for more details. 2;}
-   { (exit 1); exit 1; }; }
+  }
else
  cat conftest.$ac_ext _ACEOF
/* confdefs.h.  */



That manages to get me past the configure stage. For completeness,
here's my custom options (mostly related to me having a separate
directory for this particular build  dependencies):

export mybuild-dir=/home/tyc20/code/guile/guile-1.8.0
export CC=i586-mingw32msvc-gcc
export CPPFLAGS=-I$mybuild-dir/libgmp/include\
-I$mybuild-dir/libtool/win/include  # c PreProcessor flags.
export LDFLAGS=-L$mybuild-dir/libgmp/lib\ -L$mybuild-dir/libtool/win/lib
# export GUILE_FOR_BUILD # just leave this for now. We can use Linux
guile (older version even!) can't we?

./configure --prefix=/home/tyc20/code/guile/guile-1.8.0/win
--exec-prefix=/home/tyc20/code/guile/guile-1.8.0/win
--oldincludedir=/home/tyc20/code/guile/guile-1.8.0/win
--build=i486-linux-gnu --host=i586-mingw32msvc


That now runs fine. However, make runs into problems because
fileblocks is unavailable.

Generating libpath.h...
./guile-snarf -o load.x load.c -DHAVE_CONFIG_H -I..
-I/home/tyc20/downloads/guile-test-install-dir
-I/home/tyc20/code/guile/guile-1.8.0/libgmp/include
-I/home/tyc20/code/guile/guile-1.8.0/libtool/win/include -g -O2 -Wall
-Wmissing-prototypes -Werror
make[2]: *** No rule to make target `fileblocks.x', needed by `all'.  Stop.
make[2]: Leaving directory
`/home/tyc20/downloads/guile-test-install-dir/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tyc20/downloads/guile-test-install-dir'
make: *** [all] Error 2



It's a bit hard to track down, but I believe it's related to this line
in the Makefile

EXTRA_DOT_DOC_FILES = dynl.doc filesys.doc posix.doc net_db.doc
socket.doc win32-uname.doc win32-dirent.doc win32-socket.doc
inet_aton.doc mkstemp.doc fileblocks.doc

Looking at the other files on this line as well, it seems fileblocks.c
and fileblocks.h are needed. What gives? Were they in older guile
source-trees? I still don't know what is wrong here exactly (or if
this is a bug even), so any pointers would be appreciated. I've read
through the configure.in file (saw commented code for removing
fileblocks.o using sed, but there're also some comments about
AC_STRUCT_ST_BLOCKS, which I don't understand (yet :))).

As a general question as well (slightly off-topic), it seems the files
in EXTRA_DOT_DOC_FILES are compatibility-ish wrappers (for windows
perhaps). Are they reused from some other project or are they specific
to guile only?

Cheers everyone!
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: configure cannot test when cross-compiling should be ok

[The Senator]

Cool, thanks for the suggestions on the build process. I'll try those,
and hopefully I won't come back with errors.


Incidentally, last time I tried cross-compiling to mingw (a while ago
now) it didn't work.  I think in the end it bombed because mingw
didn't have pthreads and guile wasn't yet setup for no-threads in the
1.8 branch.  :(



Err, damn, lol. Should I use an older version of Guile perhaps? Which
version? (Or alternatively, is it hard to do that setup? I'm expecting
to mess around this a bit, so if it's a straight forward thing to do,
I can see how far I get, and provide feedback on that).

Have a good day.
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: configure cannot test when cross-compiling should be ok

[The Senator]

 eval.c:3248: warning: implicit declaration of function `alloca'

 The relevant line in the c file was I think in the debugging code,

Yes, but it's the debugging evaluator, ie. when you run with --debug
so you can see scheme-level backtraces.


Ok, so that probably needs fixing.


 so what's the best way to fix this?

I'd have thought mingw is supposed to provide alloca.h or something to
give that function.  It's Gnu C so it must exist, as __builtin_alloca
or whatever I suppose.


Indeed. There's no alloca.h in my mingw, but there's malloc.h:
[EMAIL PROTECTED]:/usr/i586-mingw32msvc/include$ ls a*.h
accctrl.h  aclapi.h  aclui.h  afxres.h  assert.h
[EMAIL PROTECTED]:/usr/i586-mingw32msvc/include$ ls *lloc*.h
malloc.h
[EMAIL PROTECTED]:/usr/i586-mingw32msvc/include$

--
Inside that malloc.h we have:

#ifdef  __cplusplus
extern C {
#endif
/*
  The _heap* memory allocation functions are supported on NT
  but not W9x. On latter, they always set errno to ENOSYS.
*/
_CRTIMP int __cdecl _heapwalk (_HEAPINFO*);
#ifdef __GNUC__
#define _alloca(x) __builtin_alloca((x))
#endif

#ifndef _NO_OLDNAMES
_CRTIMP int __cdecl heapwalk (_HEAPINFO*);
#ifdef __GNUC__
#define alloca(x) __builtin_alloca((x))
#endif
#endif  /* Not _NO_OLDNAMES */


So perhaps eval.c will need to include malloc.h, or is this autoconf's
(or even somebody else's) job?
--
Just in case this is needed, my mingw-gcc has these predefined macros:
[EMAIL PROTECTED]:~/temp$ touch test.h; i586-mingw32msvc-cpp -dM test.h | grep 
GNUC
#define __GNUC_PATCHLEVEL__ 2
#define __GNUC__ 3
#define __GNUC_MINOR__ 4

--

 I am not sure of the intent of this code. Is FIONREAD being used
 as a test for the presence of ioctl?

I think so.  If the ioctl constant FIONREAD exists then the ioctl
function exists ...

 It doesn't work here because FIONREAD (and more) is also defined in
 winsock...

Thanks.  I'll conditionalize it on ioctl existing too.

I see there's a select() in winsock.h, not sure if that's what should
be used in that bit of code ... maybe not.  I thought DOS did have a
way to ask if there was input waiting on an fd though.


??? This is out of my league, I don't know what to do about this. I'll
be happy to provide whatever information is required though.

--

I see boot-9 loads session.scm which loads documentation.scm which
uses regexps.  Bit annoying that.  I guess nobody's built anywhere
without regexps for a while.  It might work to remove the session line
from boot-9

(module-use! guile-user-module (resolve-interface '(ice-9 session)))


Yay, that does it, I finally got guile running!

[EMAIL PROTECTED] /cygdrive/c/guile2
$ ./a
guile (+ 1 1)
2
guile ((lambda (a b) (+ a b)) 4 5)
9
guile (write 'a)
aguile (write Lithp ith lithtening.)
Lithp ith lithtening.guile (exit)

Thanks for all the help!


You might be able to delete most of the guts of documentation.scm, it
shouldn't get used unless you run `help' or `procedure-documentation'
or whatever.



Well, since it runs now, I'll have a play around first, and see how far I get.

Thanks again, really appreciate that! If you, or any testers need more
details on my build options or other configurations, send me an email,
and I'll see what I can dig up.

Happy hacking!
___
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile