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

["The Senator" <senatorzergling@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5041 bytes --]

> Oops, I gave it another try and 1.8 looks ok with no threads (on
> gnu+linux at least).  I should try to keep up, eh.  You might want to
> try a native mingw build before attempting the cross compile, I'd

Hmm, that sounds like a fair bit of trouble. I choose the path of
least resistance! (even though it might be more trouble down the road
:))

> guess the former gets a lot more exercise than the latter :-).
>
> I made a fix for the st_blocks to go in the next release though.
> Thanks.

Cheers. Some updates on my progress (more bugs I think). Here's my
progress so far on trying to cross-compile guile-1.8.0 to Windows
using mingw.

------------------------------
To provide some context, previously, I did this:
Uncommented
      LIBOBJS="`echo ${LIBOBJS} | sed 's/fileblocks\.o//g'`"
from configure.in

Ran configure using the ac_cv_sys_restartable flag.

------------------------------

Also needed to use
the --disable-error-on-warning flag because of this warning:


Build process:
In file included from eval.c:5969:
eval.c: In function `deval':
eval.c:3248: warning: implicit declaration of function `alloca'

The relevant line in the c file was I think in the debugging code, so
what's the best way to fix this? It doesn't show up on native
GNU/Linux builds. I noticed that there is alloca.c in CVS, but then
this worked on on my native GNU/Linux build...

After fixing (working around?) that by disabling error on warnings,
there's a problem with undefined references to _ioctl, which I worked
around, this time by commenting out these lines in fports.c




--- ../../guile-1.8.0/libguile/fports.c 2006-02-13 02:29:11.000000000 +1300
+++ fports.c    2006-05-18 02:56:30.000000000 +1200
@@ -482,10 +482,10 @@
       < 0)
     scm_syserror ("fport_input_waiting");
   return FD_ISSET (fdes, &read_set) ? 1 : 0;
-#elif defined (FIONREAD)
-  int remir;
-  ioctl(fdes, FIONREAD, &remir);
-  return remir;
+//#elif defined (FIONREAD)
+//  int remir;
+//  ioctl(fdes, FIONREAD, &remir);
+//  return remir;
 #else
   scm_misc_error ("fport_input_waiting",
                  "Not fully implemented on this platform",





I am not sure of the intent of this code. Is FIONREAD being used
as a test for the presence of ioctl? It doesn't work here because
FIONREAD (and more) is also defined in winsock...

tyc20@leia:~$ grep -n 'FIONREAD' /usr/i586-mingw32msvc/include/*.h
/usr/i586-mingw32msvc/include/winsock2.h:138:#define FIONREAD
_IOR('f', 127, u_long)
/usr/i586-mingw32msvc/include/winsock.h:125:#define FIONREAD
_IOR('f', 127, u_long)


I'm reporting this, so hopefully someone can fix (if need be). For now,
fport_input_waiting is not implemented on my build. :)

So guile seems to build now, and I have setup everything over on a
Windows box, and manage to get this far (it's for a.exe, which is my
helloworld type application, but the same error crops up for
guile.exe):

C:\guile2>set GUILE_LOAD_PATH=c:\guileshare

C:\guile2>a
Backtrace:
In unknown file:
?: 25* (if (or # #) (try-load-module name))
?: 26 [try-load-module (ice-9 documentation)]
?: 27 (or (begin (try-module-linked name)) (try-module-autoload name) ...)
?: 28* [try-module-autoload (ice-9 documentation)]
?: 29 (let* (# # # #) (resolve-module dir-hint-module-name #f) (and # #))
...
?: 30 (letrec ((load-file #)) (dynamic-wind (lambda () #) (lambda () #) ...)
...)
?: 31* [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>
]
?: 32* [#<procedure #f ()>]
?: 33* (let* ((file #)) (cond (# => #) (# => #)))
?: 34 [#<procedure #f (full)> "c:\\guileshare/ice-9/documentation.scm"]
?: 35 [with-fluid* #<fluid 7> #f #<procedure #f ()>]
?: 36* [#<procedure #f ()>]
?: 37* [load-file #<primitive-procedure primitive-load> ...]
?: 38* [save-module-excursion #<procedure #f ()>]
?: 39 (let (# #) (dynamic-wind # thunk #))
?: 40 [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>
]
?: 41* [#<procedure #f ()>]
?: 42* [primitive-load "c:\\guileshare/ice-9/documentation.scm"]
In c:\guileshare/ice-9/documentation.scm:
93: 43* (define default-in-line-re (make-regexp "^;;; Commentary:"))
93: 44* (make-regexp "^;;; Commentary:")

c:\guileshare/ice-9/documentation.scm:93:28: In expression (make-regexp "^;;; Co
mmentary:"):
c:\guileshare/ice-9/documentation.scm:93:28: Unbound variable: make-regexp

C:\guile2>


I think I've compiled with regex support (is this supported on
Windows?), so this is as far as I get it seems. Is this fixable? Or
should I strip out documentations (a bit drastic)? I might have a hunt
around as well for this regex module (been looking). It sounds like it's
a core feature.

On an unrelated note, the LICENSE file (GPL )seems to be inconsistent:
isn't Guile on an LGPL license? Also, I think there's a wine bug (or
not? not sure) because of this problem when running "wine a.exe"

fixme:winsock:NtStatusToWSAError Status code c0000024 converted to DOS
error code 6
(This is more of a note to self).


Okies, I think I'm pretty close now... hopefully there'll be no more
of these bugs.

Have a good one.

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile