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      : address@hidden
To          : "guile-devel" address@hidden
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      : address@hidden
> To          : "guile-devel" address@hidden
> 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:
> >
> > address@hidden@_la_LIBADD = \
> >    libguile.la $(gnulib_library)
> >
> > address@hidden@_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      : address@hidden
> > To          : "guile-devel" address@hidden
> > 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" address@hidden
> > > To          : "carlo.bramix" address@hidden
> > > Cc          : "guile-devel" address@hidden
> > > 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" <address@hidden> 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/
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>