bug#13848: Aw: Re: Re: Re: bug#13848: Statically linking guile-2.0.
Jan Schukat shoo...@email.de skribis: Ok, windows paths with forward slashes work, I can now start the installed guile.exe without setting environment variables. Always nice when the inconsistent formats are the working ones :) Heh. The remaining issue is that it hangs itself after printing that it is loading q.scm. Not sure how exactly to appreoach this problem. I guess I'm gonna put a lot more debug output into the the various load functions. Or I'm gonna make debug builds and fire up gdb on windows. Or maybe you have an idea. No idea. If you could get a backtrace with gdb, that’d be helpful, yes. Ludo’.
bug#13848: Statically linking guile-2.0.
Hi Jan, Jan Schukat shoo...@email.de skribis: But when I start the installed guile.exe, the output is like this and it can't find the scheme modules: path: (/c/Users/shookie/guiletest/lib/share/guile/2.0 /c/Users/shookie/guiletest/lib/share/guile/site/2.0 /c/Users/shookie/guiletest/lib/share/guile/site /c/Users/shookie/guiletest/lib/sh are/guile) full_filename: #f compiled_filename: #f So as I suspected a conflict between mingw-paths and windows paths. I suspect the mingw paths in the installed exe are the static #defines that configure sets up since those /c/User/... paths also show up when you extract the strings fromthe binary with strings guile.exe|grep /lib. Yes. Now when I export GUILE_LOAD_PATH=/c/Users/shookie/guiletest/lib/share/guile/2.0 and GUILE_LOAD_COMPILE_PATH=/c/Users/shookie/guiletest/lib/lib/guile/2.0/ccache You miss a ‘D’ here: ‘GUILE_LOAD_COMPILED_PATH’. before invoking the installed guile.exe it finds the modules, but it doesn't seem to like compile path and tries to recompile all the modules which eventually fails with a stall, usually at q.scm or thread.scm That’s probably because of the above. Here is output from that case: $ export GUILE_LOAD_PATH=/c/Users/shookie/guiletest/lib/share/guile/2.0/ GUILE_LOAD_COMPILED_PATH=/c/Users/shookie/guiletest/lib(lib/guile/2.0/ccache/;./lib/bin/guile path: (c:/Users/shookie/guiletest/lib/share/guile/2.0/ /c/Users/shookie/guiletest/lib/share/guile/2.0 /c/Users/shookie/guiletest/lib/share/guile/site/2.0 /c/Users/shookie/guiletest/lib/share/guile/site /c/Users/shookie/guiletest/lib/sh are/guile) IIUC the difference is that the first element in the path starts with c:/ instead of /c. That’s probably because of the conversion that MinGW does when reading the environment variable (see http://www.mingw.org/wiki/Posix_path_conversion.) So that means that the file names obtained by ‘configure’ should be rewritten in Windows style, I suppose. I’m not sure exactly how this should be done though. Suggestions? Ludo’.
bug#13848: Aw: Re: bug#13848: Statically linking guile-2.0.
Embarrassing. Typo. I really appreciate you still putting up with me here :) With the correct variable name it doesnt recompile, the eventual result of running it is the same though: the program hangs whith the last output being loading q.scm. Which is strange, since that doesnt seem to be a very complicated module. Also it doesnt seem to be a module used during the build process. Regards Jan Schukat Gesendet:Sonntag, 07. April 2013 um 12:20 Uhr Von:Ludovic Courts l...@gnu.org An:Jan Schukat shoo...@email.de Cc:Andy Wingo wi...@pobox.com, 13848-d...@debbugs.gnu.org Betreff:Re: bug#13848: Statically linking guile-2.0. Hi Jan, Jan Schukat shoo...@email.de skribis: But when I start the installed guile.exe, the output is like this and it cant find the scheme modules: path: (/c/Users/shookie/guiletest/lib/share/guile/2.0 /c/Users/shookie/guiletest/lib/share/guile/site/2.0 /c/Users/shookie/guiletest/lib/share/guile/site /c/Users/shookie/guiletest/lib/sh are/guile) full_filename: #f compiled_filename: #f So as I suspected a conflict between mingw-paths and windows paths. I suspect the mingw paths in the installed exe are the static #defines that configure sets up since those /c/User/... paths also show up when you extract the strings fromthe binary with strings guile.exegrep /lib. Yes. Now when I export GUILE_LOAD_PATH=/c/Users/shookie/guiletest/lib/share/guile/2.0 and GUILE_LOAD_COMPILE_PATH=/c/Users/shookie/guiletest/lib/lib/guile/2.0/ccache You miss a D here: GUILE_LOAD_COMPILED_PATH. before invoking the installed guile.exe it finds the modules, but it doesnt seem to like compile path and tries to recompile all the modules which eventually fails with a stall, usually at q.scm or thread.scm Thats probably because of the above. Here is output from that case: export GUILE_LOAD_PATH=/c/Users/shookie/guiletest/lib/share/guile/2.0/ GUILE_LOAD_COMPILED_PATH=/c/Users/shookie/guiletest/lib(lib/guile/2.0/ccache/;./lib/bin/guile path: (c:/Users/shookie/guiletest/lib/share/guile/2.0/ /c/Users/shookie/guiletest/lib/share/guile/2.0 /c/Users/shookie/guiletest/lib/share/guile/site/2.0 /c/Users/shookie/guiletest/lib/share/guile/site /c/Users/shookie/guiletest/lib/sh are/guile) IIUC the difference is that the first element in the path starts with c:/ instead of /c. Thats probably because of the conversion that MinGW does when reading the environment variable (see http://www.mingw.org/wiki/Posix_path_conversion.) So that means that the file names obtained by configure should be rewritten in Windows style, I suppose. Im not sure exactly how this should be done though. Suggestions? Ludo.
bug#13848: Aw: Re: bug#13848: Statically linking guile-2.0.
On Sun 07 Apr 2013 18:20, Jan Schukat shoo...@email.de writes: path: (/c/Users/shookie/guiletest/lib/share/guile/2.0 /c/Users/shookie/guiletest/lib/share/guile/site/2.0 /c/Users/shookie/guiletest/lib/share/guile/site /c/Users/shookie/guiletest/lib/sh are/guile) Have you tried configuring with --prefix=c:\\Users\\shookie\\guiletest ? I.e., a windows-style path? Andy -- http://wingolog.org/
bug#13848: Aw: Re: Re: bug#13848: Statically linking guile-2.0.
Jan Schukat shoo...@email.de skribis: cd C:\Users\shookie\guiletest\lib/bin rm -f $guile_tools \ cp -pR $guild $guile_tools /bin/sh: line 4: cd: C:Usersshookieguiletestlib/bin: No such file or directory Can you try with forward slashes instead? That should fix the above issue. That is: --prefix=c:/users/shookie/guiletest/ Ludo’.
bug#13848: Aw: Re: Re: bug#13848: Statically linking guile-2.0.
Yes, tried that a while ago, lots of script errors back then. Now less, but still quite a few: CCLD libgnu.la make[6]: Entering directory /c/Users/shookie/guiletest/lib/guile-2.0/lib if test no = no; then case mingw32 in darwin[56]*) need_charset_alias=true ;; darwin* cygwin* mingw* pw32* cegcc*) need_charset_alias=false ;; *) need_charset_alias=true ;; esac ; else need_charset_alias=false ; fi ; if need_charset_alias; then /bin/sh /c/Users/shookie/guiletest/lib/guile-2.0/build-aux/install-sh -d C:Usersshookieguiletestlib/lib ; fi ; if test -f C:Usersshookieguiletestlib/lib/charset.alias; then sed -f ref-add.sed C:Usersshookieguiletestlib/lib/charset.alias C:Usersshookieguiletestlib/lib/charset.tmp ; /bin/install -c -m 644 C:Usersshookieguiletestlib/lib/charset.tmp C:Usersshookieguiletestlib/lib/charset.alias ; rm -f C:Usersshookieguiletestlib/lib/charset.tmp ; else if need_charset_alias; then sed -f ref-add.sed charset.alias C:Usersshookieguiletestlib/lib/charset.tmp ; /bin/install -c -m 644 C:Usersshookieguiletestlib/lib/charset.tmp C:Usersshookieguiletestlib/lib/charset.alias ; rm -f C:Usersshookieguiletestlib/lib/charset.tmp ; fi ; fi make[6]: Nothing to be done for install-data-am. make[6]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0/lib make[5]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0/lib make[4]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0/lib make[3]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0/lib Making install in meta make[3]: Entering directory /c/Users/shookie/guiletest/lib/guile-2.0/meta guile=C:Usersshookieguiletestlib/bin/echo guile /bin/sed -e s,x,x, ; cat ./guile-config.in /bin/sed -e s,@pkgconfigdir@,C:Usersshookieguiletestlib/lib/pkgconfig,g -e s,@PKG_CONFIG@,,g -e s,@installed_guile@,guile,g guile-config.out mv guile-config.out guile-config chmod +x guile-config make[4]: Entering directory /c/Users/shookie/guiletest/lib/guile-2.0/meta /bin/mkdir -p C:Usersshookieguiletestlib/bin /bin/install -c guile-config guild C:Usersshookieguiletestlib/bin make install-exec-hook make[5]: Entering directory /c/Users/shookie/guiletest/lib/guile-2.0/meta guild=echo -n guild /bin/sed -e s,x,x,.exe ; guile_tools=echo -n guile-tools /bin/sed -e s,x,x,.exe ; cd C:Usersshookieguiletestlib/bin rm -f guile_tools cp -pR guild guile_tools /bin/sh: line 4: cd: C:Usersshookieguiletestlib/bin: No such file or directory make[5]: *** [install-exec-hook] Error 1 make[5]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0/meta make[4]: *** [install-exec-am] Error 2 make[4]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0/meta make[3]: *** [install-am] Error 2 make[3]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0/meta make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0 make[1]: *** [install] Error 2 make[1]: Leaving directory /c/Users/shookie/guiletest/lib/guile-2.0 make: *** [lib/lib/libguile-2.0.a] Error 2 Regards Jan Schukat Gesendet:Sonntag, 07. April 2013 um 20:22 Uhr Von:Andy Wingo wi...@pobox.com An:Jan Schukat shoo...@email.de Cc:Ludovic Courts l...@gnu.org, 13848-d...@debbugs.gnu.org Betreff:Re: Aw: Re: bug#13848: Statically linking guile-2.0. On Sun 07 Apr 2013 18:20, Jan Schukat shoo...@email.de writes: path: (/c/Users/shookie/guiletest/lib/share/guile/2.0 /c/Users/shookie/guiletest/lib/share/guile/site/2.0 /c/Users/shookie/guiletest/lib/share/guile/site /c/Users/shookie/guiletest/lib/sh are/guile) Have you tried configuring with --prefix=c:Usersshookieguiletest ? I.e., a windows-style path? Andy -- http://wingolog.org/
bug#13848: Aw: Re: Re: Re: bug#13848: Statically linking guile-2.0.
Ok, windows paths with forward slashes work, I can now start the installed guile.exe without setting environment variables. Always nice when the inconsistent formats are the working ones :) The remaining issue is that it hangs itself after printing that it is loading q.scm. Not sure how exactly to appreoach this problem. I guess Im gonna put a lot more debug output into the the various load functions. Or Im gonna make debug builds and fire up gdb on windows. Or maybe you have an idea. Regards Jan Schukat Gesendet:Sonntag, 07. April 2013 um 22:00 Uhr Von:Ludovic Courts l...@gnu.org An:Jan Schukat shoo...@email.de Cc:Andy Wingo wi...@pobox.com, 13848-d...@debbugs.gnu.org Betreff:Re: Aw: Re: Re: bug#13848: Statically linking guile-2.0. Jan Schukat shoo...@email.de skribis: cd C:Usersshookieguiletestlib/bin rm -f guile_tools cp -pR guild guile_tools /bin/sh: line 4: cd: C:Usersshookieguiletestlib/bin: No such file or directory Can you try with forward slashes instead? That should fix the above issue. That is: --prefix=c:/users/shookie/guiletest/ Ludo.
bug#13848: Statically linking guile-2.0.
Finally got to look into the load path issues on windows. Did so by adding some debug output into scm_init_load_path and scm_primitive_load_path. When during the build/compile the load paths are are normal windows paths, with output like this: GEN libguile/guile-procedures.txt path:(c:\Users\shookie\guiletest\lib\guile-2.0\module c:\Users\shookie\guiletest\lib\guile-2.0\guile-readline) full_filename: c:\Users\shookie\guiletest\lib\guile-2.0\module\ice-9/boot-9.scm compiled_filename: c:\Users\shookie\guiletest\lib\guile-2.0\module\ice-9/boot-9.go full_filename: c:\Users\shookie\guiletest\lib\guile-2.0\module\ice-9/r4rs.scm compiled_filename: c:\Users\shookie\guiletest\lib\guile-2.0\module\ice-9/r4rs.go But when I start the installed guile.exe, the output is like this and it can't find the scheme modules: path: (/c/Users/shookie/guiletest/lib/share/guile/2.0 /c/Users/shookie/guiletest/lib/share/guile/site/2.0 /c/Users/shookie/guiletest/lib/share/guile/site /c/Users/shookie/guiletest/lib/sh are/guile) full_filename: #f compiled_filename: #f So as I suspected a conflict between mingw-paths and windows paths. I suspect the mingw paths in the installed exe are the static #defines that configure sets up since those /c/User/... paths also show up when you extract the strings fromthe binary with strings guile.exe|grep /lib. Now when I export GUILE_LOAD_PATH=/c/Users/shookie/guiletest/lib/share/guile/2.0 and GUILE_LOAD_COMPILE_PATH=/c/Users/shookie/guiletest/lib/lib/guile/2.0/ccache before invoking the installed guile.exe it finds the modules, but it doesn't seem to like compile path and tries to recompile all the modules which eventually fails with a stall, usually at q.scm or thread.scm Here is output from that case: $ export GUILE_LOAD_PATH=/c/Users/shookie/guiletest/lib/share/guile/2.0/ GUILE_LOAD_COMPILED_PATH=/c/Users/shookie/guiletest/lib(lib/guile/2.0/ccache/;./lib/bin/guile path: (c:/Users/shookie/guiletest/lib/share/guile/2.0/ /c/Users/shookie/guiletest/lib/share/guile/2.0 /c/Users/shookie/guiletest/lib/share/guile/site/2.0 /c/Users/shookie/guiletest/lib/share/guile/site /c/Users/shookie/guiletest/lib/sh are/guile) full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/boot-9.scm compiled_filename: #fb full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/r4rs.scm compiled_filename: #f full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/psyntax-pp.scm compiled_filename: #f full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/posix.scm compiled_filename: #f full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/networking.scm compiled_filename: #f full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/srfi\srfi-4.scm compiled_filename: #f full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/rnrs\bytevectors.scm compiled_filename: #f full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9\command-line.scm compiled_filename: c:/Users/shookie/.cache/guile/ccache/2.0-LE-4-2.0\c/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/command-line.scm.go ..snip. full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9\futures.scm compiled_filename: c:/Users/shookie/.cache/guile/ccache/2.0-LE-4-2.0\c/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/futures.scm.go full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/srfi\srfi-11.scm compiled_filename: #f ;;; compiling c:/Users/shookie/guiletest/lib/share/guile/2.0/srfi\srfi-11.scm ;;; it seems c:/Users/shookie/guiletest/lib/share/guile/2.0/srfi\srfi-11.scm ;;; is part of the compiler; skipping auto-compilation full_filename: c:/Users/shookie/guiletest/lib/share/guile/2.0/ice-9\q.scm compiled_filename: c:/Users/shookie/.cache/guile/ccache/2.0-LE-4-2.0\c/Users/shookie/guiletest/lib/share/guile/2.0/ice-9/q.scm.go And at that point it stalls. I will look more into it, but I hope this is already useful. But as usual each build takes quite a while, so progress is slow, since I always go away doing other things after I initiated a build and test-run. Regards Jan Schukat On 03/30/2013 10:27 PM, Ludovic Courtès wrote: Jan Schukat shoo...@email.de skribis: Starting the guile.exe or my own guiletest.exe still fails due to init not finding the paths to the scheme modules, Did you try after running “make install”? If you try before, it’s normal that it doesn’t find. but that is something I need to look into anyway, and will do that over Easter. It's possible that that is due to the different path treatment in mingw and windows proper, or it could just be that guile can't handle windows paths with drive letters, colons and backslashes. It can handle that now (until 2.0.7 included that didn’t work correctly.) Ludo’.
bug#13848: Statically linking guile-2.0.
Jan Schukat shoo...@email.de skribis: Starting the guile.exe or my own guiletest.exe still fails due to init not finding the paths to the scheme modules, Did you try after running “make install”? If you try before, it’s normal that it doesn’t find. but that is something I need to look into anyway, and will do that over Easter. It's possible that that is due to the different path treatment in mingw and windows proper, or it could just be that guile can't handle windows paths with drive letters, colons and backslashes. It can handle that now (until 2.0.7 included that didn’t work correctly.) Ludo’.
bug#13848: Statically linking guile-2.0.
Jan Schukat shoo...@email.de skribis: Ok finally got to it. Made 3 builds from the 194-dfd1d tarball: mingw with posix and threads, without posix and threads and linux with posix and threads. All three still have problems compiling the scheme code. All three have problems with scan-api and two of them with popen. I believe the popen-related issues are fixed by http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0id=df3d365a99311ecfe921d1dfd1848ff65112e572. You can check with a tarball from http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest/download. Thanks! Ludo’.
bug#13848: Statically linking guile-2.0.
Andy Wingo wi...@pobox.com skribis: On Sat 09 Mar 2013 14:44, Jan Schukat shoo...@email.de writes: Just tried it again on windows/mingw with the newer tarball: http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz FWIW it seems hydra is totally down right now; of course that would happen as soon as ludo goes on holiday ;) Indeed. :-) The problem was that the ‘tarball’ job would fail: --8---cut here---start-8--- perf -m 10 ./iconv_open-hpux.gperf ./iconv_open-hpux.h-t /bin/sh: gperf: command not found make[2]: *** [iconv_open-hpux.h] Error 127 --8---cut here---end---8--- (From http://hydra.nixos.org/build/4395876, caused by an upgrade to glibc 2.17 etc.) Should be fixed with http://git.savannah.gnu.org/cgit/hydra-recipes.git/commit/?id=5096b05a2f552646d148ad161df023293df49536. Ludo’.
bug#13848: Statically linking guile-2.0.
Hi, On Mon 11 Mar 2013 10:30, shoo...@email.de writes: GUILEC scripts/autofrisk.go Backtrace: In ice-9/psyntax.scm: 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...] 1259: 18 [#procedure 21d8540 at ice-9/psyntax.scm:1067:36 ()] 1605: 17 [expand-simple-lambda (# . #) () (()) ...] 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()] In ice-9/boot-9.scm: 627: 15 [map #procedure 2205e10 at ice-9/psyntax.scm:1510:50 (x) ((# . #))] In ice-9/psyntax.scm: 2114: 14 [expand-let (let # #) (# #) (# # #) ...] In ice-9/boot-9.scm: 627: 13 [map #procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x) (#)] In ice-9/psyntax.scm: 1257: 12 [#procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x) (open-input-pipe #)] 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...] 579: 10 [syntax-type open-input-pipe (# #) (# # #) ...] 292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)] In unknown file: ?: 8 [module-variable #directory (scripts autofrisk) 21a8dc8 open-input-pipe] In ice-9/boot-9.scm: 2790: 7 [b #autoload (ice-9 popen) 21a86c0 open-input-pipe #f] 2579: 6 [#procedure 1d76530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure) # ...] 2850: 5 [try-module-autoload (ice-9 popen) #f] 2191: 4 [save-module-excursion #procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()] 2870: 3 [#procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()] In unknown file: ?: 2 [primitive-load-path ice-9\\popen ...] ?: 1 [load-extension libguile-2.0 scm_init_popen] In ice-9/boot-9.scm: 106: 0 [#procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args) misc-error ...] ice-9/boot-9.scm:106:20: In procedure #procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: libguile-2.0, message: The specified module could not be found. make[3]: *** [scripts/autofrisk.go] Error 1 I believe I have fixed this one (and the scan-api one). You will see a warning when building these two files but that is all. I think at this point the build should complete. New tarball: http://wingolog.org/priv/guile-2.0.7.194-dfd1d.tar.gz This has been a very long bug report, but productive. Thank you for following through with these tests, and for checking the above tarball. The next step, after moving on to actually build your application ;), is to get the test suite working. I suspect you will run into some issues. Will you please run a make check -k, and send the resulting log (if it has errors) to bug-guile@gnu.org? Thanks :-) Please include check-guile.log as well. I'll close this report, in optimistic hope that these fixes do indeed allow the build to complete. Let me know how it goes, and happy hacking! (Actually while I'm at it: would you also mail the complete set of patches that you locally apply to your copy? They'll be helpful in future reports. Thanks!) Andy -- http://wingolog.org/
bug#13848: Aw: Re: bug#13848: Statically linking guile-2.0.
Many thanks! I wont be home until Friday, but checking the new tarball will be one of the first things I do then.One more question, when I finally manage to create a self-contained/relocatable guile application on windows and mac, would that be something of interest to the main project?RegardsJan Schukat Gesendet:Mittwoch, 13. Mrz 2013 um 10:30 Uhr Von:Andy Wingo wi...@pobox.com An:shoo...@email.de Cc:Ludovic Courts l...@gnu.org, 13848-d...@debbugs.gnu.org Betreff:Re: bug#13848: Statically linking guile-2.0. Hi, On Mon 11 Mar 2013 10:30, shoo...@email.de writes: GUILEC scripts/autofrisk.go Backtrace: In ice-9/psyntax.scm: 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...] 1259: 18 [#procedure 21d8540 at ice-9/psyntax.scm:1067:36 ()] 1605: 17 [expand-simple-lambda (# . #) () (()) ...] 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()] In ice-9/boot-9.scm: 627: 15 [map #procedure 2205e10 at ice-9/psyntax.scm:1510:50 (x) ((# . #))] In ice-9/psyntax.scm: 2114: 14 [expand-let (let # #) (# #) (# # #) ...] In ice-9/boot-9.scm: 627: 13 [map #procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x) (#)] In ice-9/psyntax.scm: 1257: 12 [#procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x) (open-input-pipe #)] 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...] 579: 10 [syntax-type open-input-pipe (# #) (# # #) ...] 292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)] In unknown file: ?: 8 [module-variable #directory (scripts autofrisk) 21a8dc8 open-input-pipe] In ice-9/boot-9.scm: 2790: 7 [b #autoload (ice-9 popen) 21a86c0 open-input-pipe #f] 2579: 6 [#procedure 1d76530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure) # ...] 2850: 5 [try-module-autoload (ice-9 popen) #f] 2191: 4 [save-module-excursion #procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()] 2870: 3 [#procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()] In unknown file: ?: 2 [primitive-load-path ice-9popen ...] ?: 1 [load-extension libguile-2.0 scm_init_popen] In ice-9/boot-9.scm: 106: 0 [#procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args) misc-error ...] ice-9/boot-9.scm:106:20: In procedure #procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: libguile-2.0, message: The specified module could not be found. make[3]: *** [scripts/autofrisk.go] Error 1 I believe I have fixed this one (and the scan-api one). You will see a warning when building these two files but that is all. I think at this point the build should complete. New tarball: http://wingolog.org/priv/guile-2.0.7.194-dfd1d.tar.gz This has been a very long bug report, but productive. Thank you for following through with these tests, and for checking the above tarball. The next step, after moving on to actually build your application ;), is to get the test suite working. I suspect you will run into some issues. Will you please run a make check -k, and send the resulting log (if it has errors) to bug-guile@gnu.org? Thanks :-) Please include check-guile.log as well. Ill close this report, in optimistic hope that these fixes do indeed allow the build to complete. Let me know how it goes, and happy hacking! (Actually while Im at it: would you also mail the complete set of patches that you locally apply to your copy? Theyll be helpful in future reports. Thanks!) Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
On Mon 11 Mar 2013 02:43, shoo...@email.de writes: GUILEC scripts/autofrisk.go Backtrace: In ice-9/psyntax.scm: 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...] 1259: 18 [#procedure 2205150 at ice-9/psyntax.scm:1067:36 ()] 1605: 17 [expand-simple-lambda (# . #) () (()) ...] 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()] In ice-9/boot-9.scm: 627: 15 [map #procedure 223e8d0 at ice-9/psyntax.scm:1510:50 (x) ((# . #))] In ice-9/psyntax.scm: 2114: 14 [expand-let (let # #) (# #) (# # #) ...] In ice-9/boot-9.scm: 627: 13 [map #procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x) (#)] In ice-9/psyntax.scm: 1257: 12 [#procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x) (open-input-pipe #)] 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...] 579: 10 [syntax-type open-input-pipe (# #) (# # #) ...] 292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)] In unknown file: ?: 8 [module-variable #directory (scripts autofrisk) 2184d80 open-input-pipe] In ice-9/boot-9.scm: 2790: 7 [b #autoload (ice-9 popen) 2216d80 open-input-pipe #f] 2579: 6 [#procedure 1d05530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure) # ...] 2850: 5 [try-module-autoload (ice-9 popen) #f] 2191: 4 [save-module-excursion #procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()] 2870: 3 [#procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()] In unknown file: ?: 2 [primitive-load-path ice-9\\popen ...] ?: 1 [load-extension libguile-2.0 scm_init_popen] In ice-9/boot-9.scm: 106: 0 [#procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args) misc-error ...] ice-9/boot-9.scm:106:20: In procedure #procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: libguile-2.0, message: The specified module could not be found. make[3]: *** [scripts/autofrisk.go] Error 1 make[3]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0/module' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0' make[1]: *** [install] Error 2 make[1]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0' make: *** [lib/lib/libguile-2.0.a] Error 2 Interesting; seems to be an instance of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12202. Can you try make -k and see what other errors you uncover? At this point it has compiled pretty much all of the needed code, using the built guile, so we're really close. Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
Hi :) On Sun 10 Mar 2013 05:09, shoo...@email.de writes: The struct timespec is still an issue in a mingw build on windows, but I know how to handle it. How do you handle it, for the record? I assume you are using pthreads-w32? As I said, I build everything on windows. I have to build bdw-gc with --enable-threads=posix. If I don't, I get errors along this line: ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0xfb8): undefined reference to `GC_pthread_detach' ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x10de): undefined reference to `GC_pthread_create' ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x1221): undefined reference to `GC_pthread_detach' ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x12d1): undefined reference to `GC_pthread_create' You can build bdw-gc without threads, and then build Guile without threads. In my builds I was doing --enable-threads=posix. The problem is, when I do build bdw-gc with posix threads, the guile module compiling is all broken, it periodically drops messages like this: GUILEC ice-9/eval.go Backtrace: In unknown file: ?: 3 [apply-smob/1 #boot-closure 192c100 (_ _ _) #t ...] ?: 2 [apply-smob/1 #catch-closure 1ccee70] ?: 1 [primitive-eval ((@ # %) (begin # # #))] ?: 0 [chmod #closed: file 0 438] You passed the `GEN guile-procedures.texi' phase? If so, things are already going well. That's the first time the newly built Guile is used, and if it went through it means at least you have a functional Guile. This problem sounds similar to something Eli Zaretskii reported: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10474#14: The next problem is here: GUILEC ice-9/eval.go Backtrace: In unknown file: ?: 5 [boot-closure #t #catch-closure 231fd40 ...] ?: 4 [catch-closure] ?: 3 [primitive-eval ((@ # %) (begin # # #))] ?: 2 [chmod #input-output: ice-9/eval.go.9IiPxC 6 438] ?: 1 [boot-closure system-error chmod ...] ?: 0 [delete-file ice-9/eval.go.9IiPxC] ERROR: In procedure delete-file: ERROR: In procedure delete-file: Permission denied This happens because Guile calls fchmod, which is #define'd to -1 on MinGW. However the code is different now, than it was when Eli made his report; now if you don't have fchmod (as mingw does not), chmod only accepts strings -- and here it seems that we are trying to chmod a port. I will see what I can do here. BTW, have you tried to execute any of the guile cross-comiles you made on a windows machine? No I have not. I would like to do so, but am not really equipped for it at the moment. Your feedback here is really appreciated, thanks :) Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
Ok, the guile compilation, apart from being exceptionally slow and spouting the mentioned backtraces, is also an infinite loop in the build process on my windows/mingw. I guess I adapt my Makefile to fully support cross compilation and make patches to guile load path initialization so that it becomes relative to the executable on windows (and osx too), since you can't rely on absolute paths there and on guile even being available. Will probably take a long while, since I got other stuff to do next week too. When I got results with that, I'm gonna write again probably due to new problems. Regards Jan Schukat On 10.03.2013, at 00:06, Andy Wingo wi...@pobox.com wrote: On Sat 09 Mar 2013 14:44, Jan Schukat shoo...@email.de writes: Just tried it again on windows/mingw with the newer tarball: http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz FWIW it seems hydra is totally down right now; of course that would happen as soon as ludo goes on holiday ;) Here is a tarball I just generated from make dist: http://wingolog.org/priv/guile-2.0.7.179-94c5.tar.gz checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/c/Users/shookie/guiletest/lib/guile-2.0': configure: error: C compiler cannot create executables No idea what is happening here, this looks like a problem on your side. I fixed a bunch of things today. BTW are you using the old mingw or are you using mingw32 or mingw64? It seems that the mingw64 project (which provides both 32- and 64-bit builds) is the current thing, but I don't really know. Anyway, please give the new tarball a roll and see how it works for you. Be sure to have a relatively new mingw. I built everything myself, with all default options (except --enable-threads=pthreads in bdw-gc, and enabling dynamic builds in gmp), and it builds with only some warnings about iconv (filed with gnulib). I can't get it to run under wine however, and that must mean something is pretty wrong... Happy hacking, Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
Ok, the guile compilation, apart from being exceptionally slow and spouting the mentioned backtraces, is also an infinite loop in the build process on my windows/mingw. I guess I adapt my Makefile to fully support cross compilation and make patches to guile load path initialization so that it becomes relative to the executable on windows (and osx too), since you can't rely on absolute paths there and on guile even being available. Will probably take a long while, since I got other stuff to do next week too. When I got results with that, I'm gonna write again probably due to new problems. Regards Jan Schukat On 10.03.2013, at 00:06, Andy Wingo wi...@pobox.com wrote: On Sat 09 Mar 2013 14:44, Jan Schukat shoo...@email.de writes: Just tried it again on windows/mingw with the newer tarball: http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz FWIW it seems hydra is totally down right now; of course that would happen as soon as ludo goes on holiday ;) Here is a tarball I just generated from make dist: http://wingolog.org/priv/guile-2.0.7.179-94c5.tar.gz checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/c/Users/shookie/guiletest/lib/guile-2.0': configure: error: C compiler cannot create executables No idea what is happening here, this looks like a problem on your side. I fixed a bunch of things today. BTW are you using the old mingw or are you using mingw32 or mingw64? It seems that the mingw64 project (which provides both 32- and 64-bit builds) is the current thing, but I don't really know. Anyway, please give the new tarball a roll and see how it works for you. Be sure to have a relatively new mingw. I built everything myself, with all default options (except --enable-threads=pthreads in bdw-gc, and enabling dynamic builds in gmp), and it builds with only some warnings about iconv (filed with gnulib). I can't get it to run under wine however, and that must mean something is pretty wrong... Happy hacking, Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
On 10.03.2013, at 18:32, Andy Wingo wi...@pobox.com wrote:
Hi :)
On Sun 10 Mar 2013 05:09, shoo...@email.de writes:
The struct timespec is still an issue in a mingw build on windows, but
I know how to handle it.
How do you handle it, for the record?
by adding
#ifndef _TIMESPEC_DEFINED
struct timespec {
time_t tv_sec;
long tv_nsec;
};
#endif
to lib/stat-time.h and libguile/threads.c. Don't particularly like it, but
that's what works. If you don't wanna make that part of the main source tree, I
got no problem making a patch part of my build process. I gotta do some
patching anyway to be able to have relative/runtime initialized load paths on
windows.
I assume you are using pthreads-w32?
/* This is an implementation of the threads API of POSIX 1003.1-2001.
*
* --
*
* Pthreads-win32 - POSIX Threads Library for Win32
* Copyright(C) 1998 John E. Bossom
* Copyright(C) 1999,2005 Pthreads-win32 contributors
*
* Contact Email: r...@callisto.canberra.edu.au
That's what the pthread.h says.
As I said, I build everything on windows.
I have to build bdw-gc with --enable-threads=posix. If I don't, I get errors
along this line:
./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0xfb8):
undefined reference to `GC_pthread_detach'
./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x10de):
undefined reference to `GC_pthread_create'
./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x1221):
undefined reference to `GC_pthread_detach'
./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x12d1):
undefined reference to `GC_pthread_create'
You can build bdw-gc without threads, and then build Guile without
threads. In my builds I was doing --enable-threads=posix.
The problem is, when I do build bdw-gc with posix threads, the guile
module compiling is all broken, it periodically drops messages like
this:
GUILEC ice-9/eval.go
Backtrace:
In unknown file:
?: 3 [apply-smob/1 #boot-closure 192c100 (_ _ _) #t ...]
?: 2 [apply-smob/1 #catch-closure 1ccee70]
?: 1 [primitive-eval ((@ # %) (begin # # #))]
?: 0 [chmod #closed: file 0 438]
You passed the `GEN guile-procedures.texi' phase? If so, things are
already going well. That's the first time the newly built Guile is
used, and if it went through it means at least you have a functional
Guile.
This problem sounds similar to something Eli Zaretskii reported:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10474#14:
The next problem is here:
GUILEC ice-9/eval.go
Backtrace:
In unknown file:
?: 5 [boot-closure #t #catch-closure 231fd40 ...]
?: 4 [catch-closure]
?: 3 [primitive-eval ((@ # %) (begin # # #))]
?: 2 [chmod #input-output: ice-9/eval.go.9IiPxC 6 438]
?: 1 [boot-closure system-error chmod ...]
?: 0 [delete-file ice-9/eval.go.9IiPxC]
ERROR: In procedure delete-file:
ERROR: In procedure delete-file: Permission denied
This happens because Guile calls fchmod, which is #define'd to -1 on
MinGW.
However the code is different now, than it was when Eli made his report;
now if you don't have fchmod (as mingw does not), chmod only accepts
strings -- and here it seems that we are trying to chmod a port. I will
see what I can do here.
Sounds promising!
Regards
Jan Schukat
P.S. I guess I append some more info, namely my configure command line, and the
most interesting build output section (after that its mostly backtraces from
guile compiling):
./configure --prefix=/c/Users/shookie/guiletest/lib --disable-shared
--disable-fast-install --with-gnu-ld --disable-deprecated --enable-nls
--with-libgmp-prefix=/c/Users/shookie/guiletest/lib LIBFFI_CFLAGS='-I/c/Use
rs/shookie/guiletest/lib/lib/libffi-3.0.12/include' LIBFFI_LIBS='-lffi'
BDW_GC_LIBS='-lgc' BDW_GC_CFLAGS='-I/c/Users/shookie/guiletest/lib'
CPPFLAGS='-D HAVE_GC_SET_FINALIZER_NOTIFIER -D HAVE_GC_GET_FREE_SPACE_DIVISOR
-D HAVE_GC_GET_HEAP
_USAGE_SAFE -D HAVE_GC_SET_FINALIZE_ON_DEMAND' CFLAGS='-s' make install
….
CC libguile_2.0_la-threads.lo
threads.c: In function 'scm_pthread_cond_timedwait':
threads.c:2006:3: warning: passing argument 3 of 'pthread_cond_timedwait' from
incompatible pointer type [enabled by default]
In file included from ../lib/time.h:369:0,
from
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/sys/time.h:3,
from ../lib/sys/time.h:30,
from ../libguile/scmconfig.h:26,
from ../libguile/bdw-gc.h:24,
from threads.c:27:
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/pthread.h:1097:31:
note: expected 'const struct timespec *' but argument is of type 'const struct
scm_t_timespec *'
CC libguile_2.0_la-throw.lo
CC
bug#13848: Statically linking guile-2.0.
On Sun 10 Mar 2013 18:32, Andy Wingo wi...@pobox.com writes: The problem is, when I do build bdw-gc with posix threads, the guile module compiling is all broken, it periodically drops messages like this: GUILEC ice-9/eval.go Backtrace: In unknown file: ?: 3 [apply-smob/1 #boot-closure 192c100 (_ _ _) #t ...] ?: 2 [apply-smob/1 #catch-closure 1ccee70] ?: 1 [primitive-eval ((@ # %) (begin # # #))] ?: 0 [chmod #closed: file 0 438] I have made what might be a fix for this issue. Can you try this tarball: http://wingolog.org/priv/guile-2.0.7.182-e9381.tar.gz Thanks, Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
I immediately tried it. And after the time spec fixes it looks good so far. The first few GUILECs came through without a hitch. It takes ages though. So might be a while until you hear from me gain. Regards Jan Schukat On 10.03.2013, at 20:23, Andy Wingo wi...@pobox.com wrote: On Sun 10 Mar 2013 18:32, Andy Wingo wi...@pobox.com writes: The problem is, when I do build bdw-gc with posix threads, the guile module compiling is all broken, it periodically drops messages like this: GUILEC ice-9/eval.go Backtrace: In unknown file: ?: 3 [apply-smob/1 #boot-closure 192c100 (_ _ _) #t ...] ?: 2 [apply-smob/1 #catch-closure 1ccee70] ?: 1 [primitive-eval ((@ # %) (begin # # #))] ?: 0 [chmod #closed: file 0 438] I have made what might be a fix for this issue. Can you try this tarball: http://wingolog.org/priv/guile-2.0.7.182-e9381.tar.gz Thanks, Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
On Sun 10 Mar 2013 23:03, shoo...@email.de writes: Ok, came pretty far, but then, during the GUILEC phase it started complaining that poll is not available, poll.go was't created then, and finally it failed to install poll.go Strange. There are a few ways to work around this I guess but I ended up importing the gnulib `poll' module, which will provide `poll' on mingw. Here's a new tarball: http://wingolog.org/priv/guile-2.0.7.187-b5870.tar.gz I wonder about your compile slowness. Could it be that somehow Guile is not using the .go files that it is compiling? Normally the compile should be slow at the beginning, but as the bootstrap progresses, things speed up. I'm sure you've seen that when building on GNU/Linux. Do you not see that on your mingw build? It sounds like we're getting really close :) Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
It does get faster with time on windows too, yes, but it is overall about 3 times slower than linux compiles. But that's true for all the compiling I do on windows. Even VC projects tend to really slow compared to what I see on Linux (it is the same machine in dual boot). My guess is that this is primarily for IO reasons. There are a lot more tricks like pipes and the like that gcc and make can use on true posix systems. I will try the new tar ball right now. You'll hear from me. Regards Jan Schukat On 10.03.2013, at 23:53, Andy Wingo wi...@pobox.com wrote: On Sun 10 Mar 2013 23:03, shoo...@email.de writes: Ok, came pretty far, but then, during the GUILEC phase it started complaining that poll is not available, poll.go was't created then, and finally it failed to install poll.go Strange. There are a few ways to work around this I guess but I ended up importing the gnulib `poll' module, which will provide `poll' on mingw. Here's a new tarball: http://wingolog.org/priv/guile-2.0.7.187-b5870.tar.gz I wonder about your compile slowness. Could it be that somehow Guile is not using the .go files that it is compiling? Normally the compile should be slow at the beginning, but as the bootstrap progresses, things speed up. I'm sure you've seen that when building on GNU/Linux. Do you not see that on your mingw build? It sounds like we're getting really close :) Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
Ok, another build that got a little further. Again, after putting my two timespec definitions in. The next GUILEC to fail is this one, happens regardless of whether posix is enabled or disabled in configure: GUILEC scripts/autofrisk.go Backtrace: In ice-9/psyntax.scm: 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...] 1259: 18 [#procedure 2205150 at ice-9/psyntax.scm:1067:36 ()] 1605: 17 [expand-simple-lambda (# . #) () (()) ...] 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()] In ice-9/boot-9.scm: 627: 15 [map #procedure 223e8d0 at ice-9/psyntax.scm:1510:50 (x) ((# . #))] In ice-9/psyntax.scm: 2114: 14 [expand-let (let # #) (# #) (# # #) ...] In ice-9/boot-9.scm: 627: 13 [map #procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x) (#)] In ice-9/psyntax.scm: 1257: 12 [#procedure 223ab20 at ice-9/psyntax.scm:2114:49 (x) (open-input-pipe #)] 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...] 579: 10 [syntax-type open-input-pipe (# #) (# # #) ...] 292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)] In unknown file: ?: 8 [module-variable #directory (scripts autofrisk) 2184d80 open-input-pipe] In ice-9/boot-9.scm: 2790: 7 [b #autoload (ice-9 popen) 2216d80 open-input-pipe #f] 2579: 6 [#procedure 1d05530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure) # ...] 2850: 5 [try-module-autoload (ice-9 popen) #f] 2191: 4 [save-module-excursion #procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()] 2870: 3 [#procedure 223e7e0 at ice-9/boot-9.scm:2851:17 ()] In unknown file: ?: 2 [primitive-load-path ice-9\\popen ...] ?: 1 [load-extension libguile-2.0 scm_init_popen] In ice-9/boot-9.scm: 106: 0 [#procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args) misc-error ...] ice-9/boot-9.scm:106:20: In procedure #procedure 200ace0 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: libguile-2.0, message: The specified module could not be found. make[3]: *** [scripts/autofrisk.go] Error 1 make[3]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0/module' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0' make[1]: *** [install] Error 2 make[1]: Leaving directory `/c/Users/shookie/guiletest/lib/guile-2.0' make: *** [lib/lib/libguile-2.0.a] Error 2 On 10.03.2013, at 23:53, Andy Wingo wi...@pobox.com wrote: On Sun 10 Mar 2013 23:03, shoo...@email.de writes: Ok, came pretty far, but then, during the GUILEC phase it started complaining that poll is not available, poll.go was't created then, and finally it failed to install poll.go Strange. There are a few ways to work around this I guess but I ended up importing the gnulib `poll' module, which will provide `poll' on mingw. Here's a new tarball: http://wingolog.org/priv/guile-2.0.7.187-b5870.tar.gz I wonder about your compile slowness. Could it be that somehow Guile is not using the .go files that it is compiling? Normally the compile should be slow at the beginning, but as the bootstrap progresses, things speed up. I'm sure you've seen that when building on GNU/Linux. Do you not see that on your mingw build? It sounds like we're getting really close :) Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
Hi, On Fri 01 Mar 2013 17:19, Jan Schukat shoo...@email.de writes: But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not sure how often it is tested by the developers. Approximately never, unfortunately. However we have been improving it recently, and cross-compiling from GNU systems to MinGW is done occasionally. I will mostly address concerns about cross-compiling. Note that you should really be using Guile from stable-2.0 git and the latest MinGW. The easiest way to do that is to install a Fedora 18 VM, because they package mingw very well and are closest to upstream. I'm a Debian user and that's what I did, FWIW. I haven't yet tried with Debian itself. Also I would mention that dynamic linking should work on Windows, if all your DLLs are in the same folder. But I am ignorant and maybe that doesn't work. Also, when you link statically and the symbol resolving works differently, you have to go through some hoops to resolve boehm-gc symbols, despite the preprocessor guards: That concerns HAVE_GC_SET_FINALIZER_NOTIFIER, HAVE_GC_GET_HEAP_USAGE_SAFE, HAVE_GC_GET_FREE_SPACE_DIVISOR, HAVE_GC_SET_FINALIZE_ON_DEMAND. In guile there are statically defined fallbacks for the respective functions, that cause linker conflicts when statically linked. Those functions probably should be renamed completely to prevent this kind of problem. Are you saying that symbols with internal, static linkage inside bdw-gc conflict with static symbols inside Guile? This sounds like a misconfiguration issue. Then there is also the old problem of the conflicting definitions of struct timespec on MinGW in time.h and pthreads.h. FWIW I did not experience this in my cross-compile. The bug #13768 about scm_getpid being used in --without-posix builds I have sent already. Fixed upstream; thanks. Also, on mingw the guile-tools/guild copy script can't deal with the .exe ending. I have to configure and make once with --program-suffix=.exe to create the proper script names and files, and then again without, so they can be copied. (or find and copy them by hand between builds) Are you certain that the meta/guile and meta/guild scripts need the .exe extension? They are not EXE files. MinGW should add on .exe to programs like libguile/guile (NB: not meta/guile) as needed. Also note that I just fixed a bug in meta/guile in which it was referencing libguile/guile without the @EXEEXT@. Basically I think --program-suffix is not what you want. But then on install (processing .texi files) guile.exe fails with this message: Throw without catch before boot: Throw to key system-error with args (canonicalize-path ~A (No such file or directory) (2))Aborting. This is fixed in git, I believe. I think we're close. Can you give it another try? If needed I can handle the autogen side of things and give you a freshly prepared tarball. Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
Sorry for the long time waiting. As I said, I had to get some real work done. Just tried it again on windows/mingw with the newer tarball: http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz This one to be exact. On windows7 with mingw this is the result: checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/c/Users/shookie/guiletest/lib/guile-2.0': configure: error: C compiler cannot create executables See `config.log' for more details make: *** [lib/lib/libguile-2.0.a] Error 77 and config.log says: configure:5226: $? = 0 configure:5215: gcc -v 5 Using built-in specs. COLLECT_GCC=C:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.2 (GCC) configure:5226: $? = 0 configure:5215: gcc -V 5 gcc.exe: error: unrecognized command line option '-V' gcc.exe: fatal error: no input files compilation terminated. Regards Jan Schukat On 03/07/2013 12:12 AM, Ludovic Courtès wrote: Jan Schukat shoo...@email.de skribis: On mingw the latest source snapshot tarball (after taking care of the struct timespec trouble) ends in a compilation error on I can't really make any sense off: SNARF numbers.x numbers.c:7643:5: error: missing binary operator before token ( This is fixed by commit 6db7ee7 of the ‘stable-2.0’ branch (it will be in 2.0.8). Can you try from a tarball at http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest/download? (Wait for an hour so that the build farm has time to catch up.) Thanks, Ludo’.
bug#13848: Statically linking guile-2.0.
On 03/09/2013 10:32 AM, Andy Wingo wrote: Hi, On Fri 01 Mar 2013 17:19, Jan Schukatshoo...@email.de writes: But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not sure how often it is tested by the developers. Approximately never, unfortunately. However we have been improving it recently, and cross-compiling from GNU systems to MinGW is done occasionally. I will mostly address concerns about cross-compiling. Note that you should really be using Guile from stable-2.0 git and the latest MinGW. The easiest way to do that is to install a Fedora 18 VM, because they package mingw very well and are closest to upstream. I'm a Debian user and that's what I did, FWIW. I haven't yet tried with Debian itself. Also I would mention that dynamic linking should work on Windows, if all your DLLs are in the same folder. But I am ignorant and maybe that doesn't work. Well, I really do my linux builds and most development on linux: that's the uname -a: Linux solon 3.5.0-26-generic #40-Ubuntu SMP Tue Feb 26 19:59:36 UTC 2013 i686 athlon i686 GNU/Linux My windows builds I really do on windows7/mingw, the uname -a there: MINGW32_NT-6.1 BIAS 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys I haven't even tried to do any of that guile building on OSX, and as I understand cross-compiling from Linux to OSX is more or less impossible/a nightmare (the VLC guys do it though I think), so I will do it on my old iMac too. I really would like to do all 3 targets via cross compiles some day (especially since compilation on linux is the fastest by far), but for now I just want to get it to work and have something to build on. Also, when you link statically and the symbol resolving works differently, you have to go through some hoops to resolve boehm-gc symbols, despite the preprocessor guards: That concerns HAVE_GC_SET_FINALIZER_NOTIFIER, HAVE_GC_GET_HEAP_USAGE_SAFE, HAVE_GC_GET_FREE_SPACE_DIVISOR, HAVE_GC_SET_FINALIZE_ON_DEMAND. In guile there are statically defined fallbacks for the respective functions, that cause linker conflicts when statically linked. Those functions probably should be renamed completely to prevent this kind of problem. Are you saying that symbols with internal, static linkage inside bdw-gc conflict with static symbols inside Guile? This sounds like a misconfiguration issue. That problem I really have on Linux too. I build my own gc for static linking, and I pass the relevant environment variables to configure (I don't rely in pkg-config, because it is not easily available on windows) .You should be able to reproduce it, with my little test project. But when I don't pass those CPP guards to configure, I get compile errors. Then there is also the old problem of the conflicting definitions of struct timespec on MinGW in time.h and pthreads.h. FWIW I did not experience this in my cross-compile. That's a very old and nasty problem with the pthread headers on windows. When I was searching I found people having problems with that for years and years. The bug #13768 about scm_getpid being used in --without-posix builds I have sent already. Fixed upstream; thanks. Also, on mingw the guile-tools/guild copy script can't deal with the .exe ending. I have to configure and make once with --program-suffix=.exe to create the proper script names and files, and then again without, so they can be copied. (or find and copy them by hand between builds) Are you certain that the meta/guile and meta/guild scripts need the .exe extension? They are not EXE files. MinGW should add on .exe to programs like libguile/guile (NB: not meta/guile) as needed. Also note that I just fixed a bug in meta/guile in which it was referencing libguile/guile without the @EXEEXT@. Basically I think --program-suffix is not what you want. I guess You can really only reproduce that on windows, since that really has to do with how windows treats paths and executable file names. But then on install (processing .texi files) guile.exe fails with this message: Throw without catch before boot: Throw to key system-error with args (canonicalize-path ~A (No such file or directory) (2))Aborting. This is fixed in git, I believe. I think we're close. Can you give it another try? If needed I can handle the autogen side of things and give you a freshly prepared tarball. I tried today with this tarball: http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz Seems to have a gcc check error where a capital -V option is passed and it fails. Summary in previous email to this bug thread. Andy I will keep trying of course. I can foresee a lot of problems with libreadline and similar loadable modules that use external dynamic libraries that don't come in a standard windows install on windows too. But I plan to make some changes/patches to the load paths anyway, so they work the same everywhere for my program, so I can address that there. But until then I first need to get
bug#13848: Statically linking guile-2.0.
On Sat 09 Mar 2013 14:44, Jan Schukat shoo...@email.de writes: Just tried it again on windows/mingw with the newer tarball: http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz FWIW it seems hydra is totally down right now; of course that would happen as soon as ludo goes on holiday ;) Here is a tarball I just generated from make dist: http://wingolog.org/priv/guile-2.0.7.179-94c5.tar.gz checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/c/Users/shookie/guiletest/lib/guile-2.0': configure: error: C compiler cannot create executables No idea what is happening here, this looks like a problem on your side. I fixed a bunch of things today. BTW are you using the old mingw or are you using mingw32 or mingw64? It seems that the mingw64 project (which provides both 32- and 64-bit builds) is the current thing, but I don't really know. Anyway, please give the new tarball a roll and see how it works for you. Be sure to have a relatively new mingw. I built everything myself, with all default options (except --enable-threads=pthreads in bdw-gc, and enabling dynamic builds in gmp), and it builds with only some warnings about iconv (filed with gnulib). I can't get it to run under wine however, and that must mean something is pretty wrong... Happy hacking, Andy -- http://wingolog.org/
bug#13848: Statically linking guile-2.0.
Ok, tried the windows builds again. The struct timespec is still an issue in a mingw build on windows, but I know how to handle it. On 10.03.2013, at 00:06, Andy Wingo wi...@pobox.com wrote: On Sat 09 Mar 2013 14:44, Jan Schukat shoo...@email.de writes: Just tried it again on windows/mingw with the newer tarball: http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz FWIW it seems hydra is totally down right now; of course that would happen as soon as ludo goes on holiday ;) Here is a tarball I just generated from make dist: http://wingolog.org/priv/guile-2.0.7.179-94c5.tar.gz checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/c/Users/shookie/guiletest/lib/guile-2.0': configure: error: C compiler cannot create executables No idea what is happening here, this looks like a problem on your side. Ok, contrary to what I thought earlier, that was actually on my side: I set -rdynamic in the CFLAGS environment variable, because that is needed for the deadline module to work on linux. I guess I need to treat that differently too on each platform. I fixed a bunch of things today. BTW are you using the old mingw or are you using mingw32 or mingw64? It seems that the mingw64 project (which provides both 32- and 64-bit builds) is the current thing, but I don't really know. The paths don't seem to be a problem anymore. Great. Anyway, please give the new tarball a roll and see how it works for you. Be sure to have a relatively new mingw. I built everything myself, with all default options (except --enable-threads=pthreads in bdw-gc, and enabling dynamic builds in gmp), and it builds with only some warnings about iconv (filed with gnulib). I can't get it to run under wine however, and that must mean something is pretty wrong... Happy hacking, Andy -- http://wingolog.org/ As I said, I build everything on windows. I have to build bdw-gc with --enable-threads=posix. If I don't, I get errors along this line: ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0xfb8): undefined reference to `GC_pthread_detach' ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x10de): undefined reference to `GC_pthread_create' ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x1221): undefined reference to `GC_pthread_detach' ./.libs/libguile-2.0.a(libguile_2.0_la-threads.o):threads.c:(.text+0x12d1): undefined reference to `GC_pthread_create' The problem is, when I do build bdw-gc with posix threads, the guile module compiling is all broken, it periodically drops messages like this: GUILEC ice-9/eval.go Backtrace: In unknown file: ?: 3 [apply-smob/1 #boot-closure 192c100 (_ _ _) #t ...] ?: 2 [apply-smob/1 #catch-closure 1ccee70] ?: 1 [primitive-eval ((@ # %) (begin # # #))] ?: 0 [chmod #closed: file 0 438] and it takes ages an ages. Builds on windows are not very fast in the first place, but I stopped the build after it go stuck at building vlist for half an hour. I'm gonna start another build like that and see what it looks like when I wake up. BTW, have you tried to execute any of the guile cross-comiles you made on a windows machine? Regards Jan Schukat
bug#13848: Statically linking guile-2.0.
Jan Schukat shoo...@email.de skribis: On mingw the latest source snapshot tarball (after taking care of the struct timespec trouble) ends in a compilation error on I can't really make any sense off: SNARF numbers.x numbers.c:7643:5: error: missing binary operator before token ( This is fixed by commit 6db7ee7 of the ‘stable-2.0’ branch (it will be in 2.0.8). Can you try from a tarball at http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest/download? (Wait for an hour so that the build farm has time to catch up.) Thanks, Ludo’.
bug#13848: Statically linking guile-2.0.
Hi, Sorry for the delay. Jan Schukat shoo...@email.de skribis: ice-9/boot-9.scm:106:20: In procedure #procedure a434b00 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: scm_init_popen make[3]: *** [ice-9/popen.go] Error 1 I see: the (ice-9 popen) module depends on functionality that is missing when building with --disable-posix, so it cannot be built. This is a bug: Guile shouldn’t try to build ice-9/popen.scm when --disable-posix is used. Regarding file names on MinGW, Andy Wingo did a lot of work recently to integrate them correctly. This will be in Guile 2.0.8, but in the meantime could you try building Guile’s ‘stable-2.0’ branch from Git? git clone git://git.sv.gnu.org/guile.git git checkout stable-2.0 autoreconf -vfi ./configure make make check Thanks in advance, Ludo’.
bug#13848: Statically linking guile-2.0.
Ok, tried that on linux. autoreconf demanded automake 1.12, which isn't available via .debs on ubuntu yet, so I installed that from the sources. after that I get this error message: configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library autoreconf: running: /usr/bin/autoconf --force configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 I simply don't know enough about automake internals to even know where to begin to go about such errors. What library would such macros be defined in? And if I knew that, would I even want to do any changes there? Or is that generated from one of the dozens of scripts in the auto toolchain? I wouldn't even know where one might apply that m4_pattern_allow. What I can gather it could also just be a sign of a syntax error in the configure.ac. Regards Jan Schukat On 03/05/2013 11:22 AM, Ludovic Courtès wrote: Hi, Sorry for the delay. Jan Schukat shoo...@email.de skribis: ice-9/boot-9.scm:106:20: In procedure #procedure a434b00 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: scm_init_popen make[3]: *** [ice-9/popen.go] Error 1 I see: the (ice-9 popen) module depends on functionality that is missing when building with --disable-posix, so it cannot be built. This is a bug: Guile shouldn’t try to build ice-9/popen.scm when --disable-posix is used. Regarding file names on MinGW, Andy Wingo did a lot of work recently to integrate them correctly. This will be in Guile 2.0.8, but in the meantime could you try building Guile’s ‘stable-2.0’ branch from Git? git clone git://git.sv.gnu.org/guile.git git checkout stable-2.0 autoreconf -vfi ./configure make make check Thanks in advance, Ludo’.
bug#13848: Statically linking guile-2.0.
Jan Schukat shoo...@email.de skribis: autoreconf demanded automake 1.12, which isn't available via .debs on ubuntu yet, so I installed that from the sources. after that I get this error message: configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library autoreconf: running: /usr/bin/autoconf --force configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 You need to install the ‘gettext’ package and re-run autoreconf. Even easier: grab a tarball from http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest. Note that the reason I’m suggesting using the latest 2.0 is to fix file name problems on MinGW. So you can take the tarball from the above URL, and build from there on MinGW. Ludo’.
bug#13848: Statically linking guile-2.0.
Gettext was installed. Actually I don't know any linux distributions where it isn't installed by default. On mingw the latest source snapshot tarball (after taking care of the struct timespec trouble) ends in a compilation error on I can't really make any sense off: SNARF numbers.x numbers.c:7643:5: error: missing binary operator before token ( Seems to be another I'll handled pre-processor guard. So for now I just get some of my actual work done under linux with the normal 2.0.7 tarball and my mentioned changes and wait for 2.0.8. Then I'll try again and will find some new and some of the same old problems again and go from there and probably write again. And then I'm probably gonna wait for the 2.0.9 tarball with some new and some old problems, and write again. Regards Jan Schukat On 03/05/2013 06:25 PM, Ludovic Courtès wrote: Jan Schukatshoo...@email.de skribis: autoreconf demanded automake 1.12, which isn't available via .debs on ubuntu yet, so I installed that from the sources. after that I get this error message: configure.ac:873: warning: macro 'AM_GNU_GETTEXT' not found in library autoreconf: running: /usr/bin/autoconf --force configure.ac:900: error: possibly undefined macro: AM_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 You need to install the ‘gettext’ package and re-run autoreconf. Even easier: grab a tarball from http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest. Note that the reason I’m suggesting using the latest 2.0 is to fix file name problems on MinGW. So you can take the tarball from the above URL, and build from there on MinGW. Ludo’.
bug#13848: Statically linking guile-2.0.
Thank you for the reply! I guess it's best I send you my little test project, which is just a makefile and a different main .cc file for each platform. Although it's work in progress, it makes what I'm doing reproducible and explains it. On 03/02/2013 04:28 PM, Ludovic Courtès wrote: Hello, Thanks for the report. Jan Schukat shoo...@email.de skribis: But then on install (processing .texi files) guile.exe fails with this message: Throw without catch before boot: Throw to key system-error with args (canonicalize-path ~A (No such file or directory) (2))Aborting. [...] Calling guile.exe directly gives this message: Throw without catch before boot: Throw to key misc-error with args (primitive-load-path Unable to find file ~S in load path (ice-9/boot-9) #f)Aborting. Does it happen when running the installed Guile? That is, you successfully run ‘make’ and ‘make install’ (and ideally ‘make check’), It's the guile.exe, guild.exe, guile-config.exe and guile-tools.exe in guile-2.0/meta. And when I trick automake into installing (by running it twice, first with --program-suffix=.exe, then without, then the installed files fail, although they are not binaries, but hashbang scripts. Same happens of course when I install the by hand into prefix/bin. I haven't gotten to compile on Linux yet in my build setup since I tried it on windows, because of the linking conflicts with the boehm-GC callbacks. That's what I'm gonna continue with now. and it’s the installed ‘guile’ binary that produces this message? As most Unix and GNU packages, Guile expects to be installed in the place specified by --prefix. If you install it elsewhere, it will fail to find its companion files, such as ice-9/boot-9.scm. So you really must install it in --prefix, and leave it there. Is it what you did? (Note that this restriction can be worked around by techniques such as found in http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/guile-relocatable.patch.) Thanks, Ludo’. Thank you for the hint. Eventually the binary should look for the scheme libraries relative to the binary position, at least on OSX where they will be placed in the .app directory and Windows. Regards Jan Schukat guiletest.tgz Description: application/compressed-tar
bug#13848: Statically linking guile-2.0.
Hello, Thanks for the report. Jan Schukat shoo...@email.de skribis: But then on install (processing .texi files) guile.exe fails with this message: Throw without catch before boot: Throw to key system-error with args (canonicalize-path ~A (No such file or directory) (2))Aborting. [...] Calling guile.exe directly gives this message: Throw without catch before boot: Throw to key misc-error with args (primitive-load-path Unable to find file ~S in load path (ice-9/boot-9) #f)Aborting. Does it happen when running the installed Guile? That is, you successfully run ‘make’ and ‘make install’ (and ideally ‘make check’), and it’s the installed ‘guile’ binary that produces this message? As most Unix and GNU packages, Guile expects to be installed in the place specified by --prefix. If you install it elsewhere, it will fail to find its companion files, such as ice-9/boot-9.scm. So you really must install it in --prefix, and leave it there. Is it what you did? (Note that this restriction can be worked around by techniques such as found in http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/guile-relocatable.patch.) Thanks, Ludo’.
bug#13848: Statically linking guile-2.0.
I'm trying to build a program that uses guile 2.0 on linux, windows and osx and finds the same environment, more or less, on all 3 platforms. That means mainly for windows reasons, I have to statically link it. So, first step is a little test system to compile it everywhere. But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not sure how often it is tested by the developers. First of all, You have to define a whole lot of environment variables. For one, there is no pkg-config on windows, but ./configure --help tells you what to do, so that's ok. Also, when you link statically and the symbol resolving works differently, you have to go through some hoops to resolve boehm-gc symbols, despite the preprocessor guards: That concerns HAVE_GC_SET_FINALIZER_NOTIFIER, HAVE_GC_GET_HEAP_USAGE_SAFE, HAVE_GC_GET_FREE_SPACE_DIVISOR, HAVE_GC_SET_FINALIZE_ON_DEMAND. In guile there are statically defined fallbacks for the respective functions, that cause linker conflicts when statically linked. Those functions probably should be renamed completely to prevent this kind of problem. Then there is also the old problem of the conflicting definitions of struct timespec on MinGW in time.h and pthreads.h. I still have to conditionally define it in stat-time.h and in thread.c - and I can't use HAVE_STRUCT_TIMESPEC as a preprocessor check, it has to be __TIMESPEC_DEFINED. Anything else leads to ugly conflicts, either already at compile time or at link time. Most likely also related to statically linking. The bug #13768 about scm_getpid being used in --without-posix builds I have sent already. Also, on mingw the guile-tools/guild copy script can't deal with the .exe ending. I have to configure and make once with --program-suffix=.exe to create the proper script names and files, and then again without, so they can be copied. (or find and copy them by hand between builds) But then on install (processing .texi files) guile.exe fails with this message: Throw without catch before boot: Throw to key system-error with args (canonicalize-path ~A (No such file or directory) (2))Aborting. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Calling guile.exe directly gives this message: Throw without catch before boot: Throw to key misc-error with args (primitive-load-path Unable to find file ~S in load path (ice-9/boot-9) #f)Aborting. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. When I copy the libguile and the header by hand and then I can build the a program, which does nothing more but calling scm_with_guile and scm_shell, get a popup window with the message: This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. So my guess is, that due to some weird path construction in automake (of which the .exe copying trouble is just another symptom), the scheme modules can't be found and built, and thus everything crashes at startup. But trying to figure out what's going on and wrong in an automake build is a major project of its own. Any hints by the experts? Regards Jan Schukat
