From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "carlo\.bramix" Newsgroups: gmane.lisp.guile.devel Subject: Re: Again on Windows support (2) Date: Wed, 1 Jul 2009 20:55:27 +0200 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1246474917 9767 80.91.229.12 (1 Jul 2009 19:01:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jul 2009 19:01:57 +0000 (UTC) To: "guile-devel" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jul 01 21:01:50 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MM53z-00054P-T6 for guile-devel@m.gmane.org; Wed, 01 Jul 2009 21:01:50 +0200 Original-Received: from localhost ([127.0.0.1]:44930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM53z-0005XG-Bo for guile-devel@m.gmane.org; Wed, 01 Jul 2009 15:01:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM4y6-0001Ug-JG for guile-devel@gnu.org; Wed, 01 Jul 2009 14:55:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM4xz-0001R3-8h for guile-devel@gnu.org; Wed, 01 Jul 2009 14:55:39 -0400 Original-Received: from [199.232.76.173] (port=41485 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM4xy-0001Qu-L2 for guile-devel@gnu.org; Wed, 01 Jul 2009 14:55:34 -0400 Original-Received: from cp-out4.libero.it ([212.52.84.104]:53863) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM4xx-0006Aw-6G for guile-devel@gnu.org; Wed, 01 Jul 2009 14:55:33 -0400 Original-Received: from libero.it (192.168.17.1) by cp-out4.libero.it (8.5.107) id 4A487572002DAE55 for guile-devel@gnu.org; Wed, 1 Jul 2009 20:55:27 +0200 X-Sensitivity: 3 X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 213.203.169.135 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8815 Archived-At: 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 t= he upgrade, the problem of splitted parameter described in previous email= s disappeared when the executable is lauched with bash. While the problem seems to be solved at msys level, the compilation of gu= ile 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 per= fectly 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/.li= bs into libguile/. Compilation continued again, until it reached this point: make[2]: Entering directory `/home/Carlo/guile/module' GUILE_AUTO_COMPILE=3D0 ../meta/uninstalled-env guile-tools compile -o "ic= e-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 i= t was working, then a Windows dialogbox appeared with the message of segm= entation 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 becaus= e 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 wra= pper" that I bypassed by copying the true executable and its library on t= hat point. At the end, both "make" and "make install" were completed without any oth= er 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=3Dlibero.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 use= d 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=3Dlibero.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. Suc= cess! > > But unfortunately there is still one bit left: when doing "make insta= ll" the file cygguile-i18n-v-0-0.dll is installed into /lib directory ins= tead 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.a= m in this manner: > > > > libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LIBADD =3D \ > > libguile.la $(gnulib_library) > > > > libguile_i18n_v_@LIBGUILE_I18N_MAJOR@_la_LDFLAGS =3D \ > > -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 LIBAD= D and hopefully we have already it with libguile.la > > > > Sincerely, > > > > Carlo Bramini. > > > > ---------- Initial Header ----------- > > > > From : guile-devel-bounces+carlo.bramix=3Dlibero.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 missin= g these flags: -export-dynamic -no-undefined > > > Infact it created a static library and not a DLL, I believe it fail= ed for this reason. > > > Now I try to quickly fix it, I will retest and I will report the re= sult. > > > > > > 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" = writes: > > > > > > > > > Under Cygwin, compilation advanced much more with newer sources= > > > > > (yeah!) > > > > > > > > Cool :) > > > > > > > > > but it gave another error: > > > > > > > > > > GUILE_AUTO_COMPILE=3D0 ../meta/uninstalled-env guile-tools comp= ile -o "ice-9/i18n. > > > > > go" "ice-9/i18n.scm" > > > > > Backtrace: > > > > [...] > > > > > ?: 34* [load-extension "libguile-i18n-v-0" "scm_init_i18n"] > > > > > > > > > > : In procedure dynamic-link in expression (load-e= xtension "libguile-i18n-v-0" "scm_init_i18n"): > > > > > : 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 h= ave > > > > dynamic library loading working, that it's just a problem with th= e i18n > > > > lib. > > > > > > > > Good luck, > > > > > > > > Andy > > > > -- > > > > http://wingolog.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > > >