Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 7/18/2010 9:07 PM, Charles Wilson wrote: stuff Sorry about the date. Blame 'git format-patch'. -- Chuck
[PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
* libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New function sets libtool variable $to_host_path_cmd, and employs cache. AC_SUBSTs $to_host_path_cmd, as well. (_LT_SETUP): Require it. * tests/testsuite.at: Ensure to_host_path_cmd is passed as a variable setting on the configure line for (new testsuite) tests. * Makefile.am: Ensure to_host_path_cmd is included in TEST_ENVIRONMENT so that it is passed to (old testsuite) tests. * libltdl/config/ltmain.m4sh (func_cygpath): New function. (func_init_to_host_pathlist_cmd): New function. (func_to_host_path): Refactored to... (now uses eval $to_host_path_cmd). (func_wine_to_win32_path): Here. New function. (func_msys_to_win32): Here. New function. (func_path_convert_check): Here. New function. (func_noop_path_convert): Here. New function. (func_msys_to_mingw_path_convert): Here. New function. (func_cygwin_to_mingw_path_convert): Here. New function. (func_nix_to_mingw_path_convert): Here. New function. (func_msys_to_cygwin_path_convert): New function. (func_nix_to_cygwin_path_convert): New function. (func_to_host_pathlist): Refactored to... (now uses eval $to_host_pathlist_cmd and func_init_to_host_pathlist_cmd). (func_pathlist_convert_check): Here. New function. (func_pathlist_front_back_pathsep): Here. New function. (func_wine_to_win32_pathlist): Here. New function. (func_noop_pathlist_convert): Here. New function. (func_msys_to_mingw_pathlist_convert): Here. New function. (func_cygwin_to_mingw_pathlist_convert): Here. New function. (func_nix_to_mingw_pathlist_convert): Here. New function. (func_msys_to_cygwin_pathlist_convert): New function. (func_nix_to_cygwin_pathlist_convert): New function. --- Originally posted here: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg6.html but much changed since then. This version actually resembles closely version 5, below -- and the link there includes a good summary discussion particularly intended for those who had forgotten all the context and previous discussion concerning this patch, over the intervening 6 months. Since it's now been 14 months later...it's still a good review. So go read it. See also http://www.cygwin.com/ml/cygwin/2009-02/msg00555.html but ignore the rest of the thread; there was not a single on-topic reply and nobody responded to my call for test. :-( version 2: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html version 3: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00233.html version 3a (an overlay on version 3) http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00238.html More disucssion here: http://lists.gnu.org/archive/html/libtool-patches/2009-02/msg00010.html version 4 (squashed 3 and 3a): http://lists.gnu.org/archive/html/libtool-patches/2009-02/msg00012.html version 5 (ignore the bogus changelog and the first URL in this message): http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00030.html but the other two URLs in that message are relevant and accurate). Interesting background discussion here: http://cygwin.com/ml/cygwin/2009-01/msg00808.html The original motivation was to enable correct cwrapper *execution* when cross-compiling to a cygwin target (from linux, primarily) -- where the $build machine was (a) x86 (b) and had wine (c) and had a cygwin installation that could be executed under wine. However, the framework is, I think, useful for other situations -- and it is a strict improvement for unix-mingw and cygwin-mingw cross compilation, IMO, because it (a) cleans up and refactors the existing hodgepodge of case statements for path translation, by (b) moving a lot of that over to libtool.m4, and (c) uses cacheable -- and thus overridable -- indirection vars to invoke the correct refactored path translation function (this override capability is needed for the lie to me use case; see cygwin-mingw (lie) below). That's good, because in the interim between Jan 2009 and now, things outside of libtool's control have changed: Running cygwin under wine has always been...complicated, but at least in the relatively recent past simple .exe's and especially cygpath.exe could be executed without issue. As of cygwin-1.7, that no longer appears to be true; I can only occassionally get any cygwin application to execute under wine without coredumping -- including cygpath. This might be PIBKAC, since I have updated/reinstalled my linux OS two or three times since then; OTOH others have reported difficulties with cygwin-1.7 on wine, too. Fortunately, the default behavior implemented by this patch (for *nix-cygwin cross) relies on the value of the user-set variable LT_CYGPATH (whose value is, obviously, by default empty). In that case, the path-conversion logic for unix-cygwin halts after the interim unix-dos conversion, complains about the empty LT_CYGPATH value, and continues without error. The result of this is simply the status quo: the wrapper exe won't work correctly, and you won't be able to launch
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 7/18/2010 9:07 PM, Charles Wilson wrote: cygwin-mingw cross (faked) cygwin-mingw cross (lie) to follow in a later message. linux-mingw cross == linux-mingw (old tests): 2 of 100 FAIL, 6 SKIP FAIL: tests/demo-hardcode.test FAIL: tests/depdemo-relink.test Don't know if these are regressions or not; will recheck without this patch. Not regressions; I get the same results without this patch. linux-cygwin cross (LT_CYGPATH not set) === linux-cygwin (old tests): 1 of 114 FAIL, 10 SKIP FAIL: tests/demo-hardcode.test Ditto: don't know if this is a regression or not; will recheck without this patch. Not a regression; same results without this patch. linux-cygwin (new tests): AWFUL. 23 unexpected failures 32 skip I don't expect any difference WITH LT_CYGPATH set, because cygpath-1.7 (and, indeed, all cygwin-1.7 programs) seems to crash under wine anyway. I need to investigate this and re-run in this configuration without this patch, to verify that these failures are not regressions. I don't *think* the changes in this patch could have caused them... Also not regressions. In fact, the unmodified version is actually even worse; it fails the following tests which the patched version does not (the patched version skips all three): 39: Link order of deplibs FAILED (link-order2.at:125) 100: template test with subdirs FAILED (template.at:243) 101: C++ static constructors FAILED (ctor.at:65) I'm not sure what's going on here, but it obviously is not a problem with this patch. I suspect my cygwin cross compiler may actually be broken; it's a brand new build, and I've never done a linux-cygwin compiler before...it's possible I messed something up: i686-pc-cygwin-gcc can compile hello_world.c and the result works ok when copied back to the windows machine. However, i686-pc-cygwin-g++ is not so lucky; hello_world.cpp's exe coredumps on win32 if used with the cygwin-provided cygstdc++-6.dll. When used with the cygstdc++-6.dll built as part of the cross toolchain, it doesn't coredump -- but doesn't print anything to stdout either. So...I'm thinking my cygwin cross compiler is borked. I'll look in to the issue...but I don't think it should hold up this patch. You might think it odd that I created this patch, originally, to assist the linux-cygwin scenario, when I didn't actually have or use a toolchain of that type. Well, that's true: I tested everything involved in the nix-cygwin path of this patch (path conversion sh functions, etc) as much as I could in vitro, but never could test that part in vivo. I kept hoping SOMEBODY on the cygwin list would respond to my Call For Testing, but no such luck. Therefore, I finally attempted to create my own linux-cygwin toolchain, but...it's early days yet for that. -- Chuck
Link Time Optimization
I've been searching mailing list for supporting -flto in libtool, and seen several (commited?) patches. The problem is that I've tried git version of libtool (trunk) and still it is not supported since any program will compile with -flto (for example, mysql-5.1.50). Then, I have several questions: - Are the lto patches already commited to trunk, or are they in some other branch? - When will be (officially, or alpha) supported lto in libtool, in which version is planned to? Thanks, and sorry if I am missing something, but I couldn't find this info on google :) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linux to windows cross compile af a dll
[adding libtool] On 08/24/2010 10:42 AM, Joost Kraaijeveld wrote: *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. It seems to be related to http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/libtool.html Is the hack that is mentioned necessary or is there another solution? This seems like it is a question more appropriate for the libtool list. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linux to windows cross compile af a dll
Hello, * Eric Blake wrote on Tue, Aug 24, 2010 at 06:47:51PM CEST: On 08/24/2010 10:42 AM, Joost Kraaijeveld wrote: *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. It seems to be related to http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/libtool.html Is the hack that is mentioned necessary or is there another solution? Which ./libtool --version is your package using? With 2.2.10, no hacks should be necessary. If 2.2.10 is still not working right, please post the output of the failing 'libtool --mode=link' command, with --debug added as first argument after libtool. Thank you. Replies can drop the automake list from Cc:. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
Hello David, * David wrote on Tue, Aug 24, 2010 at 06:32:22PM CEST: I've been searching mailing list for supporting -flto in libtool, and seen several (commited?) patches. not yet committed, unfortunately; I had hoped for feedback from a person knowledgeable with WinCE, but that didn't happen. Oh well. Since my Great Plan for automated testing is read to be deployed this weekend, I think I'll have another go at testing the proposed patches; they change commands on a lot of different systems, and I want to make sure they work before committing under the 72hour rule as Gary suggested before. So, unless problems show up, they should hopefully appear in 2.2.12, due fairly soon. The problem is that I've tried git version of libtool (trunk) and still it is not supported since any program will compile with -flto (for example, mysql-5.1.50). Thanks for mentioning that, I will test the patches on this package then. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
Hey On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * David wrote on Tue, Aug 24, 2010 at 06:32:22PM CEST: I've been searching mailing list for supporting -flto in libtool, and seen several (commited?) patches. not yet committed, unfortunately; I had hoped for feedback from a person knowledgeable with WinCE, but that didn't happen. Oh well. sorry, i didn't follow the thread. What is the problem with WinCE ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
Hello Vincent, * Vincent Torri wrote on Tue, Aug 24, 2010 at 07:09:18PM CEST: On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * David wrote on Tue, Aug 24, 2010 at 06:32:22PM CEST: I've been searching mailing list for supporting -flto in libtool, and seen several (commited?) patches. not yet committed, unfortunately; I had hoped for feedback from a person knowledgeable with WinCE, but that didn't happen. Oh well. sorry, i didn't follow the thread. That's unfortunate, because it cost us a couple of months now. :-/ I Cc:ed you on the thread, was that wrong? How can we reach you? What is the problem with WinCE ? See here: http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9990 http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9769 To repeat the question: can I assume that the preprocessor symbol _WIN32_WCE is defined for wince code, and usually not defined for non-wince code? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
That's unfortunate, because it cost us a couple of months now. :-/ I Cc:ed you on the thread, was that wrong? How can we reach you? What is the problem with WinCE ? See here: http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9990 http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9769 To repeat the question: can I assume that the preprocessor symbol _WIN32_WCE is defined for wince code, and usually not defined for non-wince code? Yes. _WIN32_WCE is defined only on Windows CE platform. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On Tue, 24 Aug 2010, Ralf Wildenhues wrote: Vincent, what about the other question I asked: * Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST: I Cc:ed you on the thread, was that wrong? How can we reach you? Please answer this. Without somebody to ask about WinCE we *can* *not* support it. sorry, i don't really understand (my english is so ugly...). What do oyu want, exactly ? a mail ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
* Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST: On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST: I Cc:ed you on the thread, was that wrong? How can we reach you? Please answer this. Without somebody to ask about WinCE we *can* *not* support it. sorry, i don't really understand (my english is so ugly...). What do oyu want, exactly ? a mail ? English: In order to be able to support Libtool on WinCE, we need somebody to be able to test it regularly, for example before releases; also, we need to be able to ask questions about it now and then. Are you able to do this for us? I can try to ask questions in French, but it's not practical to wait months for answers. Thank you. French: Pour être en mesure de soutenir Libtool sur WinCE, nous avons besoin de quelqu'un pour être de pouvoir le tester régulièrement, par exemple, avant de presse; aussi, nous devons être en mesure de poser des questions à ce sujet ici et là. Êtes-vous capable de le faire pour nous? Je peux essayer de poser des questions en français, mais ce n'est pas pratique pour attendre des mois pour obtenir des réponses. Merci. (Cela a été traduit translate.google.com) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linux to windows cross compile af a dll
On Tue, 2010-08-24 at 18:53 +0200, Ralf Wildenhues wrote: Which ./libtool --version is your package using? With 2.2.10, no hacks should be necessary. If 2.2.10 is still not working right, please post the output of the failing 'libtool --mode=link' command, with --debug added as first argument after libtool. Thank you. j...@panoramix:~$ libtool --version ltmain.sh (GNU libtool) 2.2.6b I will try with 2.2.10.1 from Debian experimental. -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linux to windows cross compile af a dll
On Tue, 2010-08-24 at 18:53 +0200, Ralf Wildenhues wrote: If 2.2.10 is still not working right, please post the output of the failing 'libtool --mode=link' command, with --debug added as first argument after libtool. Thank you. I am sorry to say but it fails. Attached the output from the command as requested. BTW: I am not linking with import libraries but to dll's, which afaik should work? -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl debug.txt.tar.bz2 Description: application/bzip-compressed-tar signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linux to windows cross compile af a dll
Based on the debug output I changed the names of the Boost dll's from boost_xxx.dll to libboost_xxx.dll and the warning went away. I was under the impression that the search order for libraries was: libxxx.dll.a xxx.dll.a libxxx.a libxxx.dll xxx.dll Apparently it is not so. This trick did NOT work for the static boost_regex-mt. I tried it with prefixing lib, and with .a and .lib as extension. Any ideas anyone? TIA -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On Martes 24 Agosto 2010 21:32:13 Ralf Wildenhues escribió: * Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST: On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST: I Cc:ed you on the thread, was that wrong? How can we reach you? Please answer this. Without somebody to ask about WinCE we *can* *not* support it. sorry, i don't really understand (my english is so ugly...). What do oyu want, exactly ? a mail ? English: In order to be able to support Libtool on WinCE, we need somebody to be able to test it regularly, for example before releases; also, we need to be able to ask questions about it now and then. Are you able to do this for us? I can try to ask questions in French, but it's not practical to wait months for answers. Thank you. French: Pour être en mesure de soutenir Libtool sur WinCE, nous avons besoin de quelqu'un pour être de pouvoir le tester régulièrement, par exemple, avant de presse; aussi, nous devons être en mesure de poser des questions à ce sujet ici et là. Êtes-vous capable de le faire pour nous? Je peux essayer de poser des questions en français, mais ce n'est pas pratique pour attendre des mois pour obtenir des réponses. Merci. (Cela a été traduit translate.google.com) Cheers, Ralf Instead of relying in only one person and possibly waiting for his response, how about to start supporting it in all other arches and disabling it on untested arches like WinCE? For example in compile time, or so on. That's just an idea, but I feel like lto is something that is sufficient important to be tested as soon as possible, and, imho, gives as a new interesting level of optimization. Personally, I use gentoo and try to optimize as much as I can.. Anyway, thanks for looking at this :) And only a suggestion, it would be usefull to have this posted somewhere (website for example...) to make searches better and avoid duplicate messages. David. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST: On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST: I Cc:ed you on the thread, was that wrong? How can we reach you? Please answer this. Without somebody to ask about WinCE we *can* *not* support it. sorry, i don't really understand (my english is so ugly...). What do oyu want, exactly ? a mail ? English: In order to be able to support Libtool on WinCE, we need somebody to be able to test it regularly, for example before releases; also, we need to be able to ask questions about it now and then. Are you able to do this for us ? Yes, I can. More precisely, i can test with cegcc. Just tell me when and what I have to do. As I have subscribed to a lot of mailing list, i have sometimes too many mails and I don't read all of them. What would be nice about the autotools ML is having, in the subject, the name of the project in bracket: Subject: [libtool] That can be done automatically (a configuration option in mailman, I guess). That would make me more aware of something important to read. regards Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
problem with mingw-w64 and libraries like libole32.a
Hey, I checked out libtool git 2 days ago and try to compile a library that uses libole32 or libws2_32 with mingw-w64 (cross compilation on linux). I get the usual message: *** Warning: linker path does not have real file for library -lole32. etc... No problem with mingw. A guy from mingw-w64 told me that it worked before. Could this be a regression ? thank you Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On Wed, 25 Aug 2010, David wrote: On Martes 24 Agosto 2010 21:32:13 Ralf Wildenhues escribió: * Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST: On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST: I Cc:ed you on the thread, was that wrong? How can we reach you? Please answer this. Without somebody to ask about WinCE we *can* *not* support it. sorry, i don't really understand (my english is so ugly...). What do oyu want, exactly ? a mail ? English: In order to be able to support Libtool on WinCE, we need somebody to be able to test it regularly, for example before releases; also, we need to be able to ask questions about it now and then. Are you able to do this for us? I can try to ask questions in French, but it's not practical to wait months for answers. Thank you. French: Pour être en mesure de soutenir Libtool sur WinCE, nous avons besoin de quelqu'un pour être de pouvoir le tester régulièrement, par exemple, avant de presse; aussi, nous devons être en mesure de poser des questions à ce sujet ici et là. Êtes-vous capable de le faire pour nous? Je peux essayer de poser des questions en français, mais ce n'est pas pratique pour attendre des mois pour obtenir des réponses. Merci. (Cela a été traduit translate.google.com) Cheers, Ralf Instead of relying in only one person and possibly waiting for his response, how about to start supporting it in all other arches and disabling it on untested arches like WinCE? For example in compile time, or so on. That's just an idea, but I feel like lto is something that is sufficient important to be tested as soon as possible, and, imho, gives as a new interesting level of optimization. Things can also be automated a bit. Cross compilation can be done with buildbot on a server, for example. That can speed up things. Vincent Torri___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with mingw-w64 and libraries like libole32.a
* Vincent Torri wrote on Wed, Aug 25, 2010 at 06:46:31AM CEST: I checked out libtool git 2 days ago and try to compile a library that uses libole32 or libws2_32 with mingw-w64 (cross compilation on linux). I get the usual message: *** Warning: linker path does not have real file for library -lole32. etc... No problem with mingw. A guy from mingw-w64 told me that it worked before. Could this be a regression ? Please rerun the 'libtool --mode=link' command with --debug added as first argument after libtool, and post both the complete command as well as all output. Thanks. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with mingw-w64 and libraries like libole32.a
On Wed, 25 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Wed, Aug 25, 2010 at 06:46:31AM CEST: I checked out libtool git 2 days ago and try to compile a library that uses libole32 or libws2_32 with mingw-w64 (cross compilation on linux). I get the usual message: *** Warning: linker path does not have real file for library -lole32. etc... No problem with mingw. A guy from mingw-w64 told me that it worked before. Could this be a regression ? Please rerun the 'libtool --mode=link' command with --debug added as first argument after libtool, and post both the complete command as well as all output. Thanks. Command: /bin/bash ../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -Wall -Wextra -Wshadow -Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/mingw64/lib -o libdl.la -rpath /home/torri/local/mingw/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la output: in the attached file. Vincent Torri libtool_mingw64_output.txt.bz2 Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
