Again on Windows support (2)

Again on Windows support (2)

[carlo.bramix]

Hello,
after a while I decided to take again guile and I tried to continue the test on mingw+msys.
In one of the messages posted in thread "Again on Windows support" it has been said to me to put in ~/.guile:

  (debug-enable 'backtrace)
  (debug-set! depth 80)

Since I was not able to do this test with .guile, I tried to modify directly the values in the sources.
Into libguile/eval.c I temporally changed the initialization of some scm_debug_opts[] as:

{ SCM_OPTION_INTEGER, "depth", 80, "Maximal length of printed backtrace." },
{ SCM_OPTION_BOOLEAN, "backtrace", 1, "Show backtrace on error." },
{ SCM_OPTION_BOOLEAN, "debug", 1, "Use the debugging evaluator." },

I hope I changed the right points.
After that, I recompiled and I got this result on console:

cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc deprecation.doc deprecated.doc discouraged.doc dynl.doc dynwind.doc eq.doc error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc futures.doc gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc gc-card.doc gettext.doc gc-segment-table.doc guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc srfi-14.doc strorder.doc strports.doc struct.doc symbols.doc threads.doc throw.doc values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc ramap.doc unif.doc dynl.doc filesys.doc posix.doc net_db.doc socket.doc win32-uname.doc win32-dirent.doc win32-socket.doc regex-posix.doc inet_aton.doc mkstemp.doc | GUILE="/home/Carlo/guile/pre-inst-guile" ../../guile-svn/scripts/snarf-check-and-output-texi          > guile-procedures.texi || { rm guile-procedures.texi; false; }
Backtrace:
In unknown file:
   ?: 0* (begin # # #)
   ?: 1* [eval-string "(apply"]

<unnamed port>: In procedure scm_i_lreadparen in expression (eval-string "(apply"):
<unnamed port>: #<unknown port>:1:7: end of file
make[3]: *** [guile-procedures.texi] Error 1

I also did the tests suggested to me in the past (first test does not print anything):

$ ./pre-inst-guile -c 1

$ ./pre-inst-guile -c '(display "foo")'
Backtrace:
In unknown file:
   ?: 0* (begin (eval-string "(display") (quit))
   ?: 1* [eval-string "(display"]

<unnamed port>: In procedure scm_i_lreadparen in expression (eval-string "(display"):
<unnamed port>: #<unknown port>:1:9: end of file

I hope you may have an idea about what it is happening.

Sincerely,

Carlo Bramini.

Re: Again on Windows support (2)

[Neil Jerram]

"carlo.bramix" <carlo.bramix@libero.it> writes:

> $ ./pre-inst-guile -c '(display "foo")'
> Backtrace:
> In unknown file:
>    ?: 0* (begin (eval-string "(display") (quit))
>    ?: 1* [eval-string "(display"]

That is weird.

Can we first rule out a problem with your shell?  What output do you
get from this?

$ set - '(display "foo")' && echo "--${1}--" && echo "--${2}--"

Regards,
     Neil

Re: Again on Windows support (2)

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

> "carlo.bramix" <carlo.bramix@libero.it> writes:
>
>> $ ./pre-inst-guile -c '(display "foo")'
>> Backtrace:
>> In unknown file:
>>    ?: 0* (begin (eval-string "(display") (quit))
>>    ?: 1* [eval-string "(display"]
>
> That is weird.
>
> Can we first rule out a problem with your shell?  What output do you
> get from this?
>
> $ set - '(display "foo")' && echo "--${1}--" && echo "--${2}--"

Assuming that that gives the expected output, i.e.

--(display "foo")--
----

my next suggestion would be to run under GDB, with a breakpoint on
scm_shell().  The invocation for doing that is

./pre-inst-guile-env ./libtool --mode=execute gdb libguile/guile -c '(display "foo")'

In scm_shell, I would expect:
argc to be 3
argv[1] to be "-c"
argv[2] to be "(display \"foo\")"
scm_get_meta_args () to return 0
and hence not to execute the "if (new_argv)" block of code.

Can you check those points?

Regards,
        Neil

Re: Again on Windows support (2)

[carlo.bramix]

Hello,
this is what I get with this test:

$ set - '(display "foo")' && echo "--${1}--" && echo "--${2}--"
--(display "foo")--
----

Sincerely,

Carlo Bramini.

---------- Initial Header -----------

From      : "Neil Jerram" neil@ossau.uklinux.net
To          : "carlo.bramix" carlo.bramix@libero.it
Cc          : "guile-devel" guile-devel@gnu.org
Date      : Wed, 17 Jun 2009 21:41:16 +0100
Subject : Re: Again on Windows support (2)

> "carlo.bramix" <carlo.bramix@libero.it> writes:
>
> > $ ./pre-inst-guile -c '(display "foo")'
> > Backtrace:
> > In unknown file:
> >    ?: 0* (begin (eval-string "(display") (quit))
> >    ?: 1* [eval-string "(display"]
>
> That is weird.
>
> Can we first rule out a problem with your shell?  What output do you
> get from this?
>
> $ set - '(display "foo")' && echo "--${1}--" && echo "--${2}--"
>
> Regards,
>      Neil
>

Re: Again on Windows support (2)

[carlo.bramix]

Hello,
this is the command that I gave me some results:

$ ./pre-inst-guile-env ./libtool --mode=execute gdb --args libguile/guile.exe -c '(display "foo")'

As you can see I added "--args" option to GDB.
Without "--args" option, GDB says:

C:\msys\1.0\home\Carlo\guile/(display "foo"): Invalid argument.
argc=1
argv[0]=C:/msys/1.0/home/Carlo/guile/libguile/.libs/guile.exe

With "--args" option I had this:

argc=4
argv[0]=C:/msys/1.0/home/Carlo/guile/libguile/.libs/guile.exe
argv[1]=-c
argv[2]=\(display\
argv[3]="foo"\)

Since I had no idea about those unknown '\' characters, I added some debug prints before scm_boot_guile():

int
main (int argc, char **argv)
{
int x;
printf("argc=%d\n",argc);
for (x=0; x<argc; x++)
printf("argv[%d]=%s\n",x,argv[x]);

scm_boot_guile (argc, argv, inner_main, 0);
return 0; /* never reached */
}

Then I launched libguile/guile.exe normally and I got this:

argc=4
argv[0]=C:/msys/1.0/home/Carlo/guile/libguile/.libs/guile.exe
argv[1]=-c
argv[2]=(display
argv[3]=foo)

In this case, no more '/' but the '"' characters around the "foo" word are disappeared.
Anyways, I seems that the parameter has been split in two...

Sincerely,

Carlo Bramini.

---------- Initial Header -----------

From      : "Neil Jerram" neil@ossau.uklinux.net
To          : "carlo.bramix" carlo.bramix@libero.it
Cc          : "guile-devel" guile-devel@gnu.org
Date      : Wed, 17 Jun 2009 22:09:08 +0100
Subject : Re: Again on Windows support (2)

> Neil Jerram <neil@ossau.uklinux.net> writes:
>
> > "carlo.bramix" <carlo.bramix@libero.it> writes:
> >
> >> $ ./pre-inst-guile -c '(display "foo")'
> >> Backtrace:
> >> In unknown file:
> >>    ?: 0* (begin (eval-string "(display") (quit))
> >>    ?: 1* [eval-string "(display"]
> >
> > That is weird.
> >
> > Can we first rule out a problem with your shell?  What output do you
> > get from this?
> >
> > $ set - '(display "foo")' && echo "--${1}--" && echo "--${2}--"
>
> Assuming that that gives the expected output, i.e.
>
> --(display "foo")--
> ----
>
> my next suggestion would be to run under GDB, with a breakpoint on
> scm_shell().  The invocation for doing that is
>
> ./pre-inst-guile-env ./libtool --mode=execute gdb libguile/guile -c '(display "foo")'
>
> In scm_shell, I would expect:
> argc to be 3
> argv[1] to be "-c"
> argv[2] to be "(display \"foo\")"
> scm_get_meta_args () to return 0
> and hence not to execute the "if (new_argv)" block of code.
>
> Can you check those points?
>
> Regards,
>         Neil
>

Re: Again on Windows support (2)

[carlo.bramix]

Hello,
I tried the same thing with cygwin I got:

$ ./pre-inst-guile -c '(display "foo")'
argc=3
argv[0]=/home/Carlo/guile/libguile/.libs/guile
argv[1]=-c
argv[2]=(display "foo")
foo

But the compilation failed even under cygwin; here you are what happens:

make[3]: Entering directory `/home/Carlo/guile/module'
/usr/bin/mkdir -p `dirname system/base/pmatch.go`
../pre-inst-guile-env ../guile-tools compile -o "system/base/pmatch.go" "/cygdrive/c/msys/1.0/home/Carlo/guile-svn/module/system/base/pmatch.scm"
argc=8
argv[0]=/home/Carlo/guile/libguile/.libs/guile
argv[1]=-e
argv[2]=(@ (scripts compile) compile)
argv[3]=-s
argv[4]=/cygdrive/c/msys/1.0/home/Carlo/guile-svn/scripts/compile
argv[5]=-o
argv[6]=system/base/pmatch.go
argv[7]=/cygdrive/c/msys/1.0/home/Carlo/guile-svn/module/system/base/pmatch.scm

Backtrace:
In unknown file:
   ?:  47* [try-load-module (system vm vm)]
   ?:  48  (or (begin (try-module-linked name)) (try-module-autoload name) ...)
   ?:  49* [try-module-autoload (system vm vm)]
   ?:  50  (let* (# # # #) (resolve-module dir-hint-module-name #f) (and # #))
     ...
   ?:  51  (letrec (#) (dynamic-wind # # #) didit)
   ?:  52* [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?:  53* [#<procedure #f ()>]
   ?:  54* (let* ((file #)) (let (# #) (cond # #)))
   ?:  55  (let ((compiled #) (source #)) (cond (# # #) (compiled #)))
     ...
   ?:  56  [with-fluid* #<fluid 7> #f #<procedure #f ()>]
   ?:  57* [#<procedure #f ()>]
   ?:  58* [load-file #<primitive-procedure primitive-load> ...]
   ?:  59* [save-module-excursion #<procedure #f ()>]
   ?:  60  (let (# #) (dynamic-wind # thunk #))
   ?:  61  [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?:  62* [#<procedure #f ()>]
   ?:  63* [primitive-load "/cygdrive/c/msys/1.0/home/Carlo/guile-svn/module/system/vm/vm.scm"]
   ?:  64* (define-module (system vm vm) #:use-module ...)
   ?:  65  (eval-when (eval load compile) (let* ((m #)) (set-current-module m) m))
     ...
   ?:  66  (let* ((m (process-define-module #))) (set-current-module m) m)
   ?:  67* [process-define-module ((system vm vm) #:use-module (#) #:use-module...)]
   ?:  68  (let* (# # # #) (beautify-user-module! module) (# kws # # ...) ...)
   ?:  69* [loop (#:use-module ((system vm frame)) #:use-module ...) () ...]
   ?:  70  (if (null? kws) (call-with-deferred-observers (lambda () # ...)) ...)
     ...
   ?:  71  (let* ((interface-args #) (interface #)) (and (eq? # #) (or # #) ...) ...)
   ?:  72* [apply #<procedure resolve-interface (name . args)> ((system vm frame))]
   ?:  73  [resolve-interface (system vm frame)]
     ...
   ?:  74  (let* (# # # # ...) (and # #) (if # public-i #))
   ?:  75* [resolve-module (system vm frame)]
   ?:  76  (if (equal? name (quote (guile))) the-root-module ...)
     ...
   ?:  77  (cond (# already) (autoload # #) (else #))
   ?:  78* [try-load-module (system vm frame)]
   ?:  79  (or (begin (try-module-linked name)) (try-module-autoload name) ...)
   ?:  80* [try-module-autoload (system vm frame)]
   ?:  81  (let* (# # # #) (resolve-module dir-hint-module-name #f) (and # #))
     ...
   ?:  82  (letrec (#) (dynamic-wind # # #) didit)
   ?:  83* [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?:  84* [#<procedure #f ()>]
   ?:  85* (let* ((file #)) (let (# #) (cond # #)))
   ?:  86  (let ((compiled #) (source #)) (cond (# # #) (compiled #)))
     ...
   ?:  87  [with-fluid* #<fluid 7> #f #<procedure #f ()>]
   ?:  88* [#<procedure #f ()>]
   ?:  89* [load-file #<primitive-procedure primitive-load> ...]
   ?:  90* [save-module-excursion #<procedure #f ()>]
   ?:  91  (let (# #) (dynamic-wind # thunk #))
   ?:  92  [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?:  93* [#<procedure #f ()>]
   ?:  94* [primitive-load "/cygdrive/c/msys/1.0/home/Carlo/guile-svn/module/system/vm/frame.scm"]
   ?:  95* (define-module (system vm frame) #:use-module ...)
   ?:  96  (eval-when (eval load compile) (let* ((m #)) (set-current-module m) m))
     ...
   ?:  97  (let* ((m (process-define-module #))) (set-current-module m) m)
   ?:  98* [process-define-module ((system vm frame) #:use-module (#) ...)]
   ?:  99  (let* (# # # #) (beautify-user-module! module) (# kws # # ...) ...)
   ?: 100* [loop (#:use-module ((system vm program)) #:use-module ...) () ...]
   ?: 101  (if (null? kws) (call-with-deferred-observers (lambda () # ...)) ...)
     ...
   ?: 102  (let* ((interface-args #) (interface #)) (and (eq? # #) (or # #) ...) ...)
   ?: 103* [apply #<procedure resolve-interface (name . args)> ((system vm program))]
   ?: 104  [resolve-interface (system vm program)]
     ...
   ?: 105  (let* (# # # # ...) (and # #) (if # public-i #))
   ?: 106* [resolve-module (system vm program)]
   ?: 107  (if (equal? name (quote (guile))) the-root-module ...)
     ...
   ?: 108  (cond (# already) (autoload # #) (else #))
   ?: 109* [try-load-module (system vm program)]
   ?: 110  (or (begin (try-module-linked name)) (try-module-autoload name) ...)
   ?: 111* [try-module-autoload (system vm program)]
   ?: 112  (let* (# # # #) (resolve-module dir-hint-module-name #f) (and # #))
     ...
   ?: 113  (letrec (#) (dynamic-wind # # #) didit)
   ?: 114* [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?: 115* [#<procedure #f ()>]
   ?: 116* (let* ((file #)) (let (# #) (cond # #)))
   ?: 117  (let ((compiled #) (source #)) (cond (# # #) (compiled #)))
     ...
   ?: 118  [with-fluid* #<fluid 7> #f #<procedure #f ()>]
   ?: 119* [#<procedure #f ()>]
   ?: 120* [load-file #<primitive-procedure primitive-load> ...]
   ?: 121* [save-module-excursion #<procedure #f ()>]
   ?: 122  (let (# #) (dynamic-wind # thunk #))
   ?: 123  [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?: 124* [#<procedure #f ()>]
   ?: 125* [primitive-load "/cygdrive/c/msys/1.0/home/Carlo/guile-svn/module/system/vm/program.scm"]
   ?: 126* [dynamic-call "scm_init_programs" #<dynamic-object "libguile">]

<unnamed port>: In procedure dynamic-func in expression (dynamic-call "scm_init_programs" (dynamic-link "libguile")):
<unnamed port>: No error
make[3]: *** [system/base/pmatch.go] Error 1
make[3]: Leaving directory `/home/Carlo/guile/module'
make[2]: *** [all-recursive] Error 1

Sincerely,

Carlo Bramini.


---------- Initial Header -----------

From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
To          : "guile-devel" guile-devel@gnu.org
Cc          :
Date      : Fri, 19 Jun 2009 10:48:23 +0200
Subject : Re: Again on Windows support (2)

> Hello,
> this is the command that I gave me some results:
>
> $ ./pre-inst-guile-env ./libtool --mode=execute gdb --args libguile/guile.exe -c '(display "foo")'
>
> As you can see I added "--args" option to GDB.
> Without "--args" option, GDB says:
>
> C:\msys\1.0\home\Carlo\guile/(display "foo"): Invalid argument.
> argc=1
> argv[0]=C:/msys/1.0/home/Carlo/guile/libguile/.libs/guile.exe
>
> With "--args" option I had this:
>
> argc=4
> argv[0]=C:/msys/1.0/home/Carlo/guile/libguile/.libs/guile.exe
> argv[1]=-c
> argv[2]=\(display\
> argv[3]="foo"\)
>
> Since I had no idea about those unknown '\' characters, I added some debug prints before scm_boot_guile():
>
> int
> main (int argc, char **argv)
> {
> int x;
> printf("argc=%d\n",argc);
> for (x=0; x<argc; x++)
> printf("argv[%d]=%s\n",x,argv[x]);
>
> scm_boot_guile (argc, argv, inner_main, 0);
> return 0; /* never reached */
> }
>
> Then I launched libguile/guile.exe normally and I got this:
>
> argc=4
> argv[0]=C:/msys/1.0/home/Carlo/guile/libguile/.libs/guile.exe
> argv[1]=-c
> argv[2]=(display
> argv[3]=foo)
>
> In this case, no more '/' but the '"' characters around the "foo" word are disappeared.
> Anyways, I seems that the parameter has been split in two...
>
> Sincerely,
>
> Carlo Bramini.
>
> ---------- Initial Header -----------
>
> From      : "Neil Jerram" neil@ossau.uklinux.net
> To          : "carlo.bramix" carlo.bramix@libero.it
> Cc          : "guile-devel" guile-devel@gnu.org
> Date      : Wed, 17 Jun 2009 22:09:08 +0100
> Subject : Re: Again on Windows support (2)
>
> > Neil Jerram <neil@ossau.uklinux.net> writes:
> >
> > > "carlo.bramix" <carlo.bramix@libero.it> writes:
> > >
> > >> $ ./pre-inst-guile -c '(display "foo")'
> > >> Backtrace:
> > >> In unknown file:
> > >>    ?: 0* (begin (eval-string "(display") (quit))
> > >>    ?: 1* [eval-string "(display"]
> > >
> > > That is weird.
> > >
> > > Can we first rule out a problem with your shell?  What output do you
> > > get from this?
> > >
> > > $ set - '(display "foo")' && echo "--${1}--" && echo "--${2}--"
> >
> > Assuming that that gives the expected output, i.e.
> >
> > --(display "foo")--
> > ----
> >
> > my next suggestion would be to run under GDB, with a breakpoint on
> > scm_shell().  The invocation for doing that is
> >
> > ./pre-inst-guile-env ./libtool --mode=execute gdb libguile/guile -c '(display "foo")'
> >
> > In scm_shell, I would expect:
> > argc to be 3
> > argv[1] to be "-c"
> > argv[2] to be "(display \"foo\")"
> > scm_get_meta_args () to return 0
> > and hence not to execute the "if (new_argv)" block of code.
> >
> > Can you check those points?
> >
> > Regards,
> >         Neil
> >
>

Re: Again on Windows support (2)

[Ludovic Courtès]

Hi Carlo,

"carlo.bramix" <carlo.bramix@libero.it> writes:

> <unnamed port>: In procedure dynamic-func in expression (dynamic-call "scm_init_programs" (dynamic-link "libguile")):
> <unnamed port>: No error

Can you try to change the following lines in <libguile/programs.h>:

--8<---------------cut here---------------start------------->8---
SCM_INTERNAL void scm_init_programs (void);
--8<---------------cut here---------------end--------------->8---

to:

--8<---------------cut here---------------start------------->8---
SCM_API void scm_init_programs (void);
--8<---------------cut here---------------end--------------->8---

Can you then recompile and report back?

Thanks in advance,
Ludovic.

Re: Again on Windows support (2)

[Neil Jerram]

"carlo.bramix" <carlo.bramix@libero.it> writes:

> Hello,
> this is what I get with this test:
>
> $ set - '(display "foo")' && echo "--${1}--" && echo "--${2}--"
> --(display "foo")--
> ----

Great, that is the expected output.

    Neil

Re: Again on Windows support (2)

[Neil Jerram]

"carlo.bramix" <carlo.bramix@libero.it> writes:

> Hello,
> this is the command that I gave me some results:
>
> $ ./pre-inst-guile-env ./libtool --mode=execute gdb --args libguile/guile.exe -c '(display "foo")'
>
> As you can see I added "--args" option to GDB.

Thanks, good point.

> Since I had no idea about those unknown '\' characters, I added some debug prints before scm_boot_guile():
>
> int 
> main (int argc, char **argv)
> {
> int x;
> printf("argc=%d\n",argc);
> for (x=0; x<argc; x++)
> printf("argv[%d]=%s\n",x,argv[x]);
>
> scm_boot_guile (argc, argv, inner_main, 0);
> return 0; /* never reached */
> }
>
> Then I launched libguile/guile.exe normally and I got this:
>
> argc=4
> argv[0]=C:/msys/1.0/home/Carlo/guile/libguile/.libs/guile.exe
> argv[1]=-c
> argv[2]=(display
> argv[3]=foo)
>
> In this case, no more '/' but the '"' characters around the "foo" word are disappeared.
> Anyways, I seems that the parameter has been split in two...

Excellent, we're getting closer.  So either it's a problem in how the
shell passes arguments to an executable, or it's a problem in how the
libguile/guile.exe wrapper passes on arguments to
libguile/.libs/guile.exe.

Can you remind me how you're compiling?  Also is guile.exe really an
executable in your build?  (On GNU/Linux it's a shell script wrapper.)

Regards,
     Neil

Re: Again on Windows support (2)

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:


> Can you remind me how you're compiling?  Also is guile.exe really an

Here I mean libguile/guile.exe------------------------^


     Neil

Re: Again on Windows support (2)

[Ludovic Courtès]

"carlo.bramix" <carlo.bramix@libero.it> writes:

> make[3]: Entering directory `/home/Carlo/guile/module'
> /usr/bin/mkdir -p `dirname system/base/pmatch.go`
> ../pre-inst-guile-env ../guile-tools compile -o "system/base/pmatch.go" "/cygdrive/c/msys/1.0/home/Carlo/guile-svn/module/system/base/pmatch.scm"

BTW, this is with an old copy of `master'.  Currently, the compilation
line looks like this:

--8<---------------cut here---------------start------------->8---
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/psyntax-pp.go" "ice-9/psyntax-pp.scm"
--8<---------------cut here---------------end--------------->8---

Can you try updating?

Thanks,
Ludo'.

Re: Again on Windows support (2)

[carlo.bramix]

I upgraded the sources to the very latest ones.
I did not change the scm_init_programs() prototype.
Under Cygwin, compilation advanced much more with newer sources (yeah!), but it gave another error:

GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/i18n.
go" "ice-9/i18n.scm"
Backtrace:
In unknown file:
   ?:  0* (begin (load "/home/Carlo/guile-git/meta/guile-tools") (# #) (quit))
   ?:  1* [main ("/home/Carlo/guile-git/meta/guile-tools" "compile" "-o" ...)]
   ?:  2  (if (let* ((t172 #)) (if t172 t172 ...)) (list-scripts) ...)
    ...
   ?:  3  [quit ...
   ?:  4* [apply #<procedure compile args863> #]
In ice-9/r4rs.scm:
  29:  5* [apply #<procedure compile args863> #]
In unknown file:
   ?:  6* [compile "-o" "ice-9/i18n.go" "ice-9/i18n.scm"]
   ?:  7* (let* ((options864 #)) (let* (#) (let* # #)))
   ?:  8  (let* ((help?865 #)) (let* (#) (let* # #)))
    ...
   ?:  9  [for-each #<procedure #f (file876)> ("ice-9/i18n.scm")]
   ?: 10* [#<procedure #f (file876)> "ice-9/i18n.scm"]
   ?: 11* [simple-format #t "wrote `~A'
" ...
   ?: 12* [lambda*:L6482 "ice-9/i18n.scm" #:output-file ...]
In system/base/compile.scm:
 148: 13* [lambda*:L6482 "ice-9/i18n.scm" #:output-file ...]
In system/base/compile.scm:
  68: 14  [call-once #<program 1012f940 at system/base/compile.scm:79:5 ()>]
In unknown file:
   ?: 15* [dynamic-wind # # #]
In system/base/compile.scm:
  81: 16* [#<program 1012f940 at system/base/compile.scm:79:5 ()>]
In unknown file:
   ?: 17* [with-throw-handler #t # #]
In system/base/compile.scm:
  83: 18* [#<program 1012f920 at system/base/compile.scm:81:9 ()>]
In system/base/compile.scm:
 151: 19  [# #<input-output: ice-9/i18n.go.6vBW9f 12>]
In system/base/compile.scm:
 194: 20  [lambda*:L6539 #<input: ice-9/i18n.scm 8> #:env ...]
In unknown file:
   ?: 21* [with-fluid* # # #]
In system/base/compile.scm:
 204: 22* [lp (#) (# ()) (# ())]
In system/base/compile.scm:
 174: 23  [lp (#) (eval-when # #) (# ()) ...]
In ice-9/boot-9.scm:
1695: 24  [save-module-excursion #]
In unknown file:
   ?: 25* [dynamic-wind # # #]
In language/scheme/compile-tree-il.scm:
  60: 26* [#<program 10138d10 at language/scheme/compile-tree-il.scm:57:3 ()>]
In ice-9/psyntax-pp.scm:
7991: 27  [# # c #]
In unknown file:
   ?: 28* [with-fluid* #<fluid 8> c ...]
In ice-9/psyntax-pp.scm:
4557: 29* [chi-top-sequence145 (#) () (#) ...]
In ice-9/psyntax-pp.scm:
4541: 30  [dobody610 ((load-extension "libguile-i18n-v-0" "scm_init_i18n")) () .
..]
In ice-9/psyntax-pp.scm:
1372: 31  [# global-call # # ...]
In ice-9/psyntax-pp.scm:
5343: 32  [top-level-eval-hook76 # #]
In unknown file:
   ?: 33* [primitive-eval ("noexpand" #)]
   ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"]

<unnamed port>: In procedure dynamic-link in expression (load-extension "libguile-i18n-v-0" "scm_init_i18n"):
<unnamed port>: file: "libguile-i18n-v-0", message: "can't open the module"
make[2]: *** [ice-9/i18n.go] Error 1

Sincerely,

Carlo Bramini.

---------- Initial Header -----------

From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
To          : guile-devel@gnu.org
Cc          :
Date      : Fri, 19 Jun 2009 20:30:55 +0200
Subject : Re: Again on Windows support (2)

> "carlo.bramix" <carlo.bramix@libero.it> writes:
>
> > make[3]: Entering directory `/home/Carlo/guile/module'
> > /usr/bin/mkdir -p `dirname system/base/pmatch.go`
> > ../pre-inst-guile-env ../guile-tools compile -o "system/base/pmatch.go" "/cygdrive/c/msys/1.0/home/Carlo/guile-svn/module/system/base/pmatch.scm"
>
> BTW, this is with an old copy of `master'.  Currently, the compilation
> line looks like this:
>
> --8<---------------cut here---------------start------------->8---
> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/psyntax-pp.go" "ice-9/psyntax-pp.scm"
> --8<---------------cut here---------------end--------------->8---
>
> Can you try updating?
>
> Thanks,
> Ludo'.
>
>
>
>

Re: Again on Windows support (2)

[Andy Wingo]

On Fri 19 Jun 2009 21:11, "carlo.bramix" <carlo.bramix@libero.it> writes:

> Under Cygwin, compilation advanced much more with newer sources
> (yeah!)

Cool :)

> but it gave another error:
>
> GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/i18n.
> go" "ice-9/i18n.scm"
> Backtrace:
[...]
>    ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"]
>
> <unnamed port>: In procedure dynamic-link in expression (load-extension "libguile-i18n-v-0" "scm_init_i18n"):
> <unnamed port>: file: "libguile-i18n-v-0", message: "can't open the
> module"

Perhaps something is wrong when linking this module. "Can't open the
module" is not a very good warning :)

If you've gotten to here, you might be able to run Guile:

$ meta/guile

If it doesn't error about srfi-1 lib loading, that means you do have
dynamic library loading working, that it's just a problem with the i18n
lib.

Good luck,

Andy
-- 
http://wingolog.org/

Re: Again on Windows support (2)

[carlo.bramix]

Hello,
Bug found.
The problem seems to happen because the libguile-i18n-v-0 is missing these flags: -export-dynamic -no-undefined
Infact it created a static library and not a DLL, I believe it failed for this reason.
Now I try to quickly fix it, I will retest and I will report the result.

Sincerely,

Carlo Bramini.


---------- Initial Header -----------

From      : "Andy Wingo" wingo@pobox.com
To          : "carlo.bramix" carlo.bramix@libero.it
Cc          : "guile-devel" guile-devel@gnu.org
Date      : Sat, 20 Jun 2009 12:53:48 +0200
Subject : Re: Again on Windows support (2)

> On Fri 19 Jun 2009 21:11, "carlo.bramix" <carlo.bramix@libero.it> writes:
>
> > Under Cygwin, compilation advanced much more with newer sources
> > (yeah!)
>
> Cool :)
>
> > but it gave another error:
> >
> > GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/i18n.
> > go" "ice-9/i18n.scm"
> > Backtrace:
> [...]
> >    ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"]
> >
> > <unnamed port>: In procedure dynamic-link in expression (load-extension "libguile-i18n-v-0" "scm_init_i18n"):
> > <unnamed port>: file: "libguile-i18n-v-0", message: "can't open the
> > module"
>
> Perhaps something is wrong when linking this module. "Can't open the
> module" is not a very good warning :)
>
> If you've gotten to here, you might be able to run Guile:
>
> $ meta/guile
>
> If it doesn't error about srfi-1 lib loading, that means you do have
> dynamic library loading working, that it's just a problem with the i18n
> lib.
>
> Good luck,
>
> Andy
> --
> http://wingolog.org/
>

Re: Again on Windows support (2)

[carlo.bramix]

Hello,
adding "-export-dynamic -no-undefined" fixed guile under cygwin.
Both "make" and "make install" are now executed without troubles. Success!
But unfortunately there is still one bit left: when doing "make install" the file cygguile-i18n-v-0-0.dll is installed into /lib directory instead of /bin.
All other DLL are correctly installed into /bin directory, just this one is an exception.
I have not idea why it happens... I hope someone has an explanation...
BTW, I have also a doubt: I changed that stuff in libguile/Makefile.am in this manner:

libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LIBADD =	\
   libguile.la $(gnulib_library)

libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS =	\
   -module -L$(builddir) -lguile			\
   -export-dynamic -no-undefined			\
   -version-info @LIBGUILE_I18N_INTERFACE@

but isn't the "-lguile" wrong into LDFLAGS? It should stay into LIBADD and hopefully we have already it with libguile.la

Sincerely,

Carlo Bramini.

---------- Initial Header -----------

From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
To          : "guile-devel" guile-devel@gnu.org
Cc          :
Date      : Mon, 22 Jun 2009 11:18:05 +0200
Subject : Re: Again on Windows support (2)

> Hello,
> Bug found.
> The problem seems to happen because the libguile-i18n-v-0 is missing these flags: -export-dynamic -no-undefined
> Infact it created a static library and not a DLL, I believe it failed for this reason.
> Now I try to quickly fix it, I will retest and I will report the result.
>
> Sincerely,
>
> Carlo Bramini.
>
>
> ---------- Initial Header -----------
>
> From      : "Andy Wingo" wingo@pobox.com
> To          : "carlo.bramix" carlo.bramix@libero.it
> Cc          : "guile-devel" guile-devel@gnu.org
> Date      : Sat, 20 Jun 2009 12:53:48 +0200
> Subject : Re: Again on Windows support (2)
>
> > On Fri 19 Jun 2009 21:11, "carlo.bramix" <carlo.bramix@libero.it> writes:
> >
> > > Under Cygwin, compilation advanced much more with newer sources
> > > (yeah!)
> >
> > Cool :)
> >
> > > but it gave another error:
> > >
> > > GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/i18n.
> > > go" "ice-9/i18n.scm"
> > > Backtrace:
> > [...]
> > >    ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"]
> > >
> > > <unnamed port>: In procedure dynamic-link in expression (load-extension "libguile-i18n-v-0" "scm_init_i18n"):
> > > <unnamed port>: file: "libguile-i18n-v-0", message: "can't open the
> > > module"
> >
> > Perhaps something is wrong when linking this module. "Can't open the
> > module" is not a very good warning :)
> >
> > If you've gotten to here, you might be able to run Guile:
> >
> > $ meta/guile
> >
> > If it doesn't error about srfi-1 lib loading, that means you do have
> > dynamic library loading working, that it's just a problem with the i18n
> > lib.
> >
> > Good luck,
> >
> > Andy
> > --
> > http://wingolog.org/
> >
>
>
>
>

Re: Again on Windows support (2)

[carlo.bramix]

Hello,
after cygwin, I tried again msys+mingw with the latest sources from GIT.
I compiled and installed libunistring (which is a new requirement), next I configured guile.
Finally I launched compilation but after a while it hangs because an error:

libtool: link: gcc -Wall -Wmissing-prototypes -Werror -g -O2 -o .libs/guile_filter_doc_snarfage.exe c-tokenize.o  /mingw/lib/libregex.dll.a /mingw/lib/libunistring.dll.a /mingw/lib/libiconv.dll.a /mingw/lib/libgmp.dll.a -lcrypt -lws2_32 /mingw/lib/libltdl.dll.a -L/mingw/lib
c-tokenize.o: In function `yyalloc':
C:/msys/1.0/home/Carlo/guile/libguile/<stdout>:2140: undefined reference to `_rpl_malloc'
collect2: ld returned 1 exit status
make[3]: *** [guile_filter_doc_snarfage.exe] Error 1

I temporally patched the generated Makefile by adding $(top_builddir)/lib/.libs/libgnu.a to LIBS variable and guile_filter_doc_snarfage.exe has been built successfully.
Evidently, it seems that guile_filter_doc_snarfage.exe needs your libgnu as dependecy, which is missing.

After fixing this little trouble, it continued to compile but it failed at the same point of older sources because the "splitted parameter" event.

Sincerely,

Carlo Bramini.

---------- Initial Header -----------

From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
To          : "guile-devel" guile-devel@gnu.org
Cc          :
Date      : Mon, 22 Jun 2009 12:22:33 +0200
Subject : Re: Again on Windows support (2)

> Hello,
> adding "-export-dynamic -no-undefined" fixed guile under cygwin.
> Both "make" and "make install" are now executed without troubles. Success!
> But unfortunately there is still one bit left: when doing "make install" the file cygguile-i18n-v-0-0.dll is installed into /lib directory instead of /bin.
> All other DLL are correctly installed into /bin directory, just this one is an exception.
> I have not idea why it happens... I hope someone has an explanation...
> BTW, I have also a doubt: I changed that stuff in libguile/Makefile.am in this manner:
>
> libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LIBADD =	\
>    libguile.la $(gnulib_library)
>
> libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS =	\
>    -module -L$(builddir) -lguile			\
>    -export-dynamic -no-undefined			\
>    -version-info @LIBGUILE_I18N_INTERFACE@
>
> but isn't the "-lguile" wrong into LDFLAGS? It should stay into LIBADD and hopefully we have already it with libguile.la
>
> Sincerely,
>
> Carlo Bramini.
>
> ---------- Initial Header -----------
>
> From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
> To          : "guile-devel" guile-devel@gnu.org
> Cc          :
> Date      : Mon, 22 Jun 2009 11:18:05 +0200
> Subject : Re: Again on Windows support (2)
>
> > Hello,
> > Bug found.
> > The problem seems to happen because the libguile-i18n-v-0 is missing these flags: -export-dynamic -no-undefined
> > Infact it created a static library and not a DLL, I believe it failed for this reason.
> > Now I try to quickly fix it, I will retest and I will report the result.
> >
> > Sincerely,
> >
> > Carlo Bramini.
> >
> >
> > ---------- Initial Header -----------
> >
> > From      : "Andy Wingo" wingo@pobox.com
> > To          : "carlo.bramix" carlo.bramix@libero.it
> > Cc          : "guile-devel" guile-devel@gnu.org
> > Date      : Sat, 20 Jun 2009 12:53:48 +0200
> > Subject : Re: Again on Windows support (2)
> >
> > > On Fri 19 Jun 2009 21:11, "carlo.bramix" <carlo.bramix@libero.it> writes:
> > >
> > > > Under Cygwin, compilation advanced much more with newer sources
> > > > (yeah!)
> > >
> > > Cool :)
> > >
> > > > but it gave another error:
> > > >
> > > > GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/i18n.
> > > > go" "ice-9/i18n.scm"
> > > > Backtrace:
> > > [...]
> > > >    ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"]
> > > >
> > > > <unnamed port>: In procedure dynamic-link in expression (load-extension "libguile-i18n-v-0" "scm_init_i18n"):
> > > > <unnamed port>: file: "libguile-i18n-v-0", message: "can't open the
> > > > module"
> > >
> > > Perhaps something is wrong when linking this module. "Can't open the
> > > module" is not a very good warning :)
> > >
> > > If you've gotten to here, you might be able to run Guile:
> > >
> > > $ meta/guile
> > >
> > > If it doesn't error about srfi-1 lib loading, that means you do have
> > > dynamic library loading working, that it's just a problem with the i18n
> > > lib.
> > >
> > > Good luck,
> > >
> > > Andy
> > > --
> > > http://wingolog.org/
> > >
> >
> >
> >
> >
>
>
>
>

Re: Again on Windows support (2)

[carlo.bramix]

Hello,
the problem with the library installed into /lib directory instead of /bin is caused by "-module" parameter into LDFLAGS.
This parameter should be moved into configure script and it must be used for platforms that really need it (at least, not for mingw and cygwin).
I also removed the "-lguile" parameter from LDFLAGS because it must use what it has been written into LIBADD.
I did this change and it worked fine on cygwin and linux Debian 5.0

Sincerely,

Carlo Bramini.


---------- Initial Header -----------

From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
To          : "guile-devel" guile-devel@gnu.org
Cc          :
Date      : Mon, 22 Jun 2009 12:22:33 +0200
Subject : Re: Again on Windows support (2)

> Hello,
> adding "-export-dynamic -no-undefined" fixed guile under cygwin.
> Both "make" and "make install" are now executed without troubles. Success!
> But unfortunately there is still one bit left: when doing "make install" the file cygguile-i18n-v-0-0.dll is installed into /lib directory instead of /bin.
> All other DLL are correctly installed into /bin directory, just this one is an exception.
> I have not idea why it happens... I hope someone has an explanation...
> BTW, I have also a doubt: I changed that stuff in libguile/Makefile.am in this manner:
>
> libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LIBADD =	\
>    libguile.la $(gnulib_library)
>
> libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS =	\
>    -module -L$(builddir) -lguile			\
>    -export-dynamic -no-undefined			\
>    -version-info @LIBGUILE_I18N_INTERFACE@
>
> but isn't the "-lguile" wrong into LDFLAGS? It should stay into LIBADD and hopefully we have already it with libguile.la
>
> Sincerely,
>
> Carlo Bramini.
>
> ---------- Initial Header -----------
>
> From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
> To          : "guile-devel" guile-devel@gnu.org
> Cc          :
> Date      : Mon, 22 Jun 2009 11:18:05 +0200
> Subject : Re: Again on Windows support (2)
>
> > Hello,
> > Bug found.
> > The problem seems to happen because the libguile-i18n-v-0 is missing these flags: -export-dynamic -no-undefined
> > Infact it created a static library and not a DLL, I believe it failed for this reason.
> > Now I try to quickly fix it, I will retest and I will report the result.
> >
> > Sincerely,
> >
> > Carlo Bramini.
> >
> >
> > ---------- Initial Header -----------
> >
> > From      : "Andy Wingo" wingo@pobox.com
> > To          : "carlo.bramix" carlo.bramix@libero.it
> > Cc          : "guile-devel" guile-devel@gnu.org
> > Date      : Sat, 20 Jun 2009 12:53:48 +0200
> > Subject : Re: Again on Windows support (2)
> >
> > > On Fri 19 Jun 2009 21:11, "carlo.bramix" <carlo.bramix@libero.it> writes:
> > >
> > > > Under Cygwin, compilation advanced much more with newer sources
> > > > (yeah!)
> > >
> > > Cool :)
> > >
> > > > but it gave another error:
> > > >
> > > > GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/i18n.
> > > > go" "ice-9/i18n.scm"
> > > > Backtrace:
> > > [...]
> > > >    ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"]
> > > >
> > > > <unnamed port>: In procedure dynamic-link in expression (load-extension "libguile-i18n-v-0" "scm_init_i18n"):
> > > > <unnamed port>: file: "libguile-i18n-v-0", message: "can't open the
> > > > module"
> > >
> > > Perhaps something is wrong when linking this module. "Can't open the
> > > module" is not a very good warning :)
> > >
> > > If you've gotten to here, you might be able to run Guile:
> > >
> > > $ meta/guile
> > >
> > > If it doesn't error about srfi-1 lib loading, that means you do have
> > > dynamic library loading working, that it's just a problem with the i18n
> > > lib.
> > >
> > > Good luck,
> > >
> > > Andy
> > > --
> > > http://wingolog.org/
> > >
> >
> >
> >
> >
>
>
>
>

Re: Again on Windows support (2)

[carlo.bramix]

Hello,
here there are the results of what I've discovered on compiling the very latest sources of guile under mingw+msys.
I sent a message into mingw-user mailing list and I discovered that I had one of the components of msys not up to date.
It seems you need msyscore to be at least 1.0.10 or newer.
Next I launched a very simple testapp for printing argc and argv: after the upgrade, the problem of splitted parameter described in previous emails disappeared when the executable is lauched with bash.
While the problem seems to be solved at msys level, the compilation of guile still failed for the same reason: splitted parameters in MSDOS format.
I discovered that now the problem is caused by the wrapper libguile/guile.exe, probably generated by libtool.
Instead, if I launch libguile/.lib/guile.exe, then the parameters are perfectly acquired.
I'm using libtool 2.2.6a.
For not starting (at least not immediately!) a fight against the sources of libtool, I just copied guile.exe and libguile-18.dll from libguile/.libs into libguile/.
Compilation continued again, until it reached this point:

make[2]: Entering directory `/home/Carlo/guile/module'
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/psyntax-pp.go" "../../guile-git/module/ice-9/psyntax-pp.scm"

It processed for about 20 seconds, harddisk led was flashing so I guess it was working, then a Windows dialogbox appeared with the message of segmentation fault error (urgh!).
This problem needs to be investigated a bit more...

I also tried to compile an older version of guile, it's 1.8.6.
I had to re-create all scripts with autogen.sh and a newer libtool because it gave to me some errors without sense on linking.
Next I had to hack a bit the code related to timespec structure.
During compilation I faced again the problem with "not good guile.exe wrapper" that I bypassed by copying the true executable and its library on that point.
At the end, both "make" and "make install" were completed without any other error (YEAH!!!).

I will report something more about the crash as soon as possible.

Sincerely,

Carlo Bramini.


---------- Initial Header -----------

From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
To          : "guile-devel" guile-devel@gnu.org
Cc          :
Date      : Fri, 26 Jun 2009 20:45:25 +0200
Subject : Re: Again on Windows support (2)

> Hello,
> the problem with the library installed into /lib directory instead of /bin is caused by "-module" parameter into LDFLAGS.
> This parameter should be moved into configure script and it must be used for platforms that really need it (at least, not for mingw and cygwin).
> I also removed the "-lguile" parameter from LDFLAGS because it must use what it has been written into LIBADD.
> I did this change and it worked fine on cygwin and linux Debian 5.0
>
> Sincerely,
>
> Carlo Bramini.
>
>
> ---------- Initial Header -----------
>
> From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
> To          : "guile-devel" guile-devel@gnu.org
> Cc          :
> Date      : Mon, 22 Jun 2009 12:22:33 +0200
> Subject : Re: Again on Windows support (2)
>
> > Hello,
> > adding "-export-dynamic -no-undefined" fixed guile under cygwin.
> > Both "make" and "make install" are now executed without troubles. Success!
> > But unfortunately there is still one bit left: when doing "make install" the file cygguile-i18n-v-0-0.dll is installed into /lib directory instead of /bin.
> > All other DLL are correctly installed into /bin directory, just this one is an exception.
> > I have not idea why it happens... I hope someone has an explanation...
> > BTW, I have also a doubt: I changed that stuff in libguile/Makefile.am in this manner:
> >
> > libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LIBADD =	\
> >    libguile.la $(gnulib_library)
> >
> > libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS =	\
> >    -module -L$(builddir) -lguile			\
> >    -export-dynamic -no-undefined			\
> >    -version-info @LIBGUILE_I18N_INTERFACE@
> >
> > but isn't the "-lguile" wrong into LDFLAGS? It should stay into LIBADD and hopefully we have already it with libguile.la
> >
> > Sincerely,
> >
> > Carlo Bramini.
> >
> > ---------- Initial Header -----------
> >
> > From      : guile-devel-bounces+carlo.bramix=libero.it@gnu.org
> > To          : "guile-devel" guile-devel@gnu.org
> > Cc          :
> > Date      : Mon, 22 Jun 2009 11:18:05 +0200
> > Subject : Re: Again on Windows support (2)
> >
> > > Hello,
> > > Bug found.
> > > The problem seems to happen because the libguile-i18n-v-0 is missing these flags: -export-dynamic -no-undefined
> > > Infact it created a static library and not a DLL, I believe it failed for this reason.
> > > Now I try to quickly fix it, I will retest and I will report the result.
> > >
> > > Sincerely,
> > >
> > > Carlo Bramini.
> > >
> > >
> > > ---------- Initial Header -----------
> > >
> > > From      : "Andy Wingo" wingo@pobox.com
> > > To          : "carlo.bramix" carlo.bramix@libero.it
> > > Cc          : "guile-devel" guile-devel@gnu.org
> > > Date      : Sat, 20 Jun 2009 12:53:48 +0200
> > > Subject : Re: Again on Windows support (2)
> > >
> > > > On Fri 19 Jun 2009 21:11, "carlo.bramix" <carlo.bramix@libero.it> writes:
> > > >
> > > > > Under Cygwin, compilation advanced much more with newer sources
> > > > > (yeah!)
> > > >
> > > > Cool :)
> > > >
> > > > > but it gave another error:
> > > > >
> > > > > GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o "ice-9/i18n.
> > > > > go" "ice-9/i18n.scm"
> > > > > Backtrace:
> > > > [...]
> > > > >    ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"]
> > > > >
> > > > > <unnamed port>: In procedure dynamic-link in expression (load-extension "libguile-i18n-v-0" "scm_init_i18n"):
> > > > > <unnamed port>: file: "libguile-i18n-v-0", message: "can't open the
> > > > > module"
> > > >
> > > > Perhaps something is wrong when linking this module. "Can't open the
> > > > module" is not a very good warning :)
> > > >
> > > > If you've gotten to here, you might be able to run Guile:
> > > >
> > > > $ meta/guile
> > > >
> > > > If it doesn't error about srfi-1 lib loading, that means you do have
> > > > dynamic library loading working, that it's just a problem with the i18n
> > > > lib.
> > > >
> > > > Good luck,
> > > >
> > > > Andy
> > > > --
> > > > http://wingolog.org/
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>