Re: "configure cannot test when cross-compiling" should be ok
"The Senator" <[EMAIL PROTECTED]> writes: > > So perhaps eval.c will need to include malloc.h, Yep, thanks, I made that change. > or is this autoconf's (or even somebody else's) job? The blob of alloca code that's there is (or should be) the autoconf manual recommendation. > ??? 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. Oh, I just meant that char-waiting code can probably do better that what it currently can. I don't want to actually work on it, not for DOS, but if anyone can say how it should be done then we can add some code. >> (module-use! guile-user-module (resolve-interface '(ice-9 session))) I made the change below to documentation.scm which looks like it fixes the problem for me in a --disable-regex build. Obviously the affected functions won't run, but at least it should get to the repl. --- documentation.scm.~1.10.2.1.~ 2006-02-14 08:58:55.0 +1100 +++ documentation.scm 2006-05-28 08:34:41.0 +1000 @@ -90,14 +90,21 @@ ;; ;; commentary extraction ;; -(define default-in-line-re (make-regexp "^;;; Commentary:")) -(define default-after-line-re (make-regexp "^;;; Code:")) -(define default-scrub (let ((dirt (make-regexp "^;+"))) -(lambda (line) - (let ((m (regexp-exec dirt line))) -(if m (match:suffix m) line) (define (file-commentary filename . cust) ; (IN-LINE-RE AFTER-LINE-RE SCRUB) + + ;; These are constants but are not at the top level because the repl in + ;; boot-9.scm loads session.scm which in turn loads this file, and we want + ;; that to work even even when regexps are not available (ie. make-regexp + ;; doesn't exist), as for instance is the case on mingw. + ;; + (define default-in-line-re (make-regexp "^;;; Commentary:")) + (define default-after-line-re (make-regexp "^;;; Code:")) + (define default-scrub (let ((dirt (make-regexp "^;+"))) + (lambda (line) + (let ((m (regexp-exec dirt line))) + (if m (match:suffix m) line) + ;; fixme: might be cleaner to use optargs here... (let ((in-line-re (if (> 1 (length cust)) default-in-line-re ___ 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
> 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
Re: "configure cannot test when cross-compiling" should be ok
"The Senator" <[EMAIL PROTECTED]> writes: > > 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. > 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. > 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. > 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 > > I think I've compiled with regex support (is this supported on > Windows?), Probably not unless mingw is providing it somehow. 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))) > should I strip out documentations (a bit drastic)? 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. > I might have a hunt > around as well for this regex module (been looking). We can make arrangments to link to some good third party bits. > On an unrelated note, the LICENSE file (GPL )seems to be inconsistent: > isn't Guile on an LGPL license? Yes, for all the library parts. Test programs and example programs I'm not so sure, but the bits you need to link into an executable are supposed to be LGPL. > 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 c024 converted to DOS > error code 6 > (This is more of a note to self). Dunno what 6 means. I assume the exit status is low on the list of priorities just yet though :-). ___ 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
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.0 +1300
+++ fports.c2006-05-18 02:56:30.0 +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...
[EMAIL PROTECTED]:~$ 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 # # #
]
?: 32* [#]
?: 33* (let* ((file #)) (cond (# => #) (# => #)))
?: 34 [# "c:\\guileshare/ice-9/documentation.scm"]
?: 35 [with-fluid* # #f #]
?: 36* [#]
?: 37* [load-file # ...]
?: 38* [save-module-excursion #]
?: 39 (let (# #) (dynamic-wind # thunk #))
?: 40 [dynamic-wind # # #
]
?: 41* [#]
?: 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 c024 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.
___
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" <[EMAIL PROTECTED]> writes: > > Which version? 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 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. ___ 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" <[EMAIL PROTECTED]> writes:
>
> checking for restartable system calls... configure: error: cannot run
> test program while cross compiling
You should be able to force it with
./configure ac_cv_sys_restartable_syscalls=yes
or "no" if that's the right answer, I don't know how system calls and
signals interact on mingw.
> --- 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; }; }
> + }
That's probably not what you want.
___
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" <[EMAIL PROTECTED]> writes:
>
> I've read
> through the configure.in file (saw commented code for removing
> fileblocks.o using sed,
Yep, that's a bug in the guile configure I think. Try uncommenting
it,
LIBOBJS="`echo ${LIBOBJS} | sed 's/fileblocks\.o//g'`"
Or creating an empty fileblocks.c, guile shouldn't actually need
anything in it.
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. :(
> 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?
Most come from autoconf.
___
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
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
"configure cannot test when cross-compiling" should be ok
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
