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...@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...@libguile_i18n_major@_la_LIBADD = \ > libguile.la $(gnulib_library) > > libguile_i18n...@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...@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" wi...@pobox.com > > To : "carlo.bramix" carlo.bra...@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.bra...@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/ > > > > > > > > > > > > > > >
