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      : 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/
> > >
> >
> >
> >
> >
>
>
>
>