Re: cross compilation to w32
Roumen Petrov wrote: Ralf Wildenhues wrote: * Roumen Petrov wrote on Sun, Mar 09, 2008 at 05:01:30PM CET: [SNIP] Hmm during the tests tests/demo/helldl.exe is compiled many times. First is ok, later don't produce output(exit code 127) and tests/demo/.libs/helldl.exe crash. Roumen ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cross compilation to w32
* Roumen Petrov wrote on Sun, Mar 09, 2008 at 05:01:30PM CET: > > Please find attached my check.log (12 of 77 tests failed). Can you also post verbose log output, and also test the new testsuite's results (see README for details on how to do all this)? Thanks. > Tested libtool 2.2. > env: > gcc (GCC) 3.4.5 (mingw special) > wine(0.9.24). > > Make install is fine. > > Did you run tests/install inside wine session or you use binfmt for run > w32 applications test inside linux ? binfmt. Cheers, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cross compilation to w32
Ralf Wildenhues wrote: Hello, we have a couple of problems wrt. cross compilation to w32 in 2.2. When I cross-compile from GNU/Linux to MinGW using Debian's mingw32 packages (i586-mingw32msvc-gcc etc.), then link mode already requires executing a host program; for example: cd tests/demo /bin/sh -x ./libtool --tag=CC --mode=link i586-mingw32msvc-gcc -g -O2 -export-dynamic -dlpreopen libhello.la -L/usr/i586-mingw32msvc/lib -o helldl.exe dlmain.o [...] + ./helldl.exe --lt-dump-script Wine exited with a successful status + exit 0 This means that building will fail on systems without a simulator. The other problem I've stumbled over so far is this one: the *_ltshwrapper file has DOS line endings. This causes 'make install' to fail, because the native /bin/sh cannot parse the script: /bin/sh ./libtool --mode=install /usr/bin/install -c 'hell.exe' '/home/ralf/download/cvs/libtool/HEAD/build-mingw/_inst/bin/hell.exe' : command not foundapper: line 2: : command not foundapper: line 11: : command not foundapper: line 16: ./.libs/hell_ltshwrapper: line 26: syntax error near unexpected token `newline' ./.libs/hell_ltshwrapper: line 26: ` case `(set -o) 2>/dev/null` in *posix*) se' -o posix;; esac libtool: install: invalid libtool wrapper script `./.libs/hell_ltshwrapper' Does anybody see easy ways out? Verbose old suite log and new suite testsuite.log attached, bzip2 (tests run with CVS HEAD plus a couple of pending patches). Thanks, Ralf Please find attached my check.log (12 of 77 tests failed). Tested libtool 2.2. env: gcc (GCC) 3.4.5 (mingw special) wine(0.9.24). Make install is fine. Did you run tests/install inside wine session or you use binfmt for run w32 applications test inside linux ? Roumen make check-recursive make[1]: Entering directory `[LOCAL]/mingw-cross/libtool-2.2/.build' make[2]: Entering directory `[LOCAL]/mingw-cross/libtool-2.2/.build' make check-TESTS check-local make[3]: Entering directory `[LOCAL]/mingw-cross/libtool-2.2/.build' PASS: tests/link.test PASS: tests/link-2.test PASS: tests/nomode.test PASS: tests/objectlist.test PASS: tests/quote.test PASS: tests/sh.test PASS: tests/suffix.test PASS: tests/tagtrace.test PASS: tests/cdemo-static.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-static.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/demo-inst.test PASS: tests/demo-unst.test PASS: tests/depdemo-static.test PASS: tests/depdemo-make.test PASS: tests/depdemo-exec.test PASS: tests/depdemo-inst.test PASS: tests/depdemo-unst.test PASS: tests/mdemo-static.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/cdemo-conf.test PASS: tests/cdemo-make.test SKIP: tests/cdemo-exec.test PASS: tests/demo-conf.test PASS: tests/demo-make.test SKIP: tests/demo-exec.test FAIL: tests/demo-inst.test SKIP: tests/demo-unst.test SKIP: tests/demo-deplibs.test PASS: tests/depdemo-conf.test PASS: tests/depdemo-make.test SKIP: tests/depdemo-exec.test FAIL: tests/depdemo-inst.test SKIP: tests/depdemo-unst.test PASS: tests/mdemo-conf.test PASS: tests/mdemo-make.test SKIP: tests/mdemo-exec.test FAIL: tests/mdemo-inst.test SKIP: tests/mdemo-unst.test FAIL: tests/mdemo-dryrun.test PASS: tests/mdemo2-conf.test SKIP: tests/mdemo2-make.test SKIP: tests/mdemo2-exec.test PASS: tests/pdemo-conf.test PASS: tests/pdemo-make.test SKIP: tests/pdemo-exec.test FAIL: tests/pdemo-inst.test PASS: tests/demo-nofast.test PASS: tests/demo-make.test SKIP: tests/demo-exec.test FAIL: tests/demo-inst.test SKIP: tests/demo-unst.test PASS: tests/depdemo-nofast.test PASS: tests/depdemo-make.test SKIP: tests/depdemo-exec.test FAIL: tests/depdemo-inst.test SKIP: tests/depdemo-unst.test PASS: tests/demo-pic.test PASS: tests/demo-make.test SKIP: tests/demo-exec.test PASS: tests/demo-nopic.test PASS: tests/demo-make.test SKIP: tests/demo-exec.test PASS: tests/cdemo-shared.test PASS: tests/cdemo-make.test SKIP: tests/cdemo-exec.test PASS: tests/demo-shared.test PASS: tests/demo-make.test SKIP: tests/demo-exec.test FAIL: tests/demo-inst.test FAIL: tests/demo-hardcode.test FAIL: tests/demo-relink.test PASS: tests/demo-noinst-link.test SKIP: tests/demo-unst.test PASS: tests/depdemo-shared.test PASS: tests/depdemo-make.test SKIP: tests/depdemo-exec.test FAIL: tests/depdemo-inst.test SKIP: tests/depdemo-relink.test SKIP: tests/depdemo-unst.test PASS: tests/mdemo-shared.test PASS: tests/mdemo-make.test SKIP: tests/mdemo-exec.test FAIL: tests/mdemo-inst.test SKIP: tests/mdemo-unst.test PASS: tests/cdemo-undef.test PASS: tests/cdemo-make.test SKIP: tests/cdemo-exec.test PASS: tests/tagdemo-static.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test PASS: tests/tagdemo-conf.test PASS: tests/tagdemo-make.test SKIP: tests/tagdemo-exec.test PASS: tests/tagdemo-shared.test PASS: tests/tagdemo-make.test SKIP: tests/tagdemo-exec.test PASS: tests/tagdemo-undef.test PASS: tests/tagdemo-make.te
Re: cross compilation to w32
Ralf Wildenhues wrote:
Does anybody see easy ways out?
Well, for the second problem there are two solutions. (1) always ensure
that the script is emitted with unix line endings, or (2) specify
$TARGETSHELL=/emulation/environment/sh when cross-compiling.
Obviously, (2) is the easiest, because getting rid of the requirement
for an emulator is going to take a bit more work. (1) is slightly more
difficult, and doesn't solve the emulator problem -- but at least
doesn't compound the problem.
For cygwin/msys, (1) means for --lt-dump-script, using setmode() on
stdout here:
if (strcmp (argv[i], dumpscript_opt) == 0)
{
<<< setmode here? >>>
printf ("%s", script_text);
return 0;
}
and for "normal" operation, changing this:
/* note: do NOT use "wt" here! -- defer to underlying
* mount type on cygwin
*/
if ((shwrapper = fopen (newargz[1], "w")) == 0)
to
/* always use binary mode */
if ((shwrapper = fopen (newargz[1], "wb")) == 0)
Both cygwin and msys's shell will work with unix line endings,
regardless of cygwin's underlying mount type, etc.
Of course, both of these suggestions (setmode, and using "wb") are
win32-isms, and will only work as written above if we continue to use
$LTCC as described below:
# we should really use a build-platform specific compiler
# here, but OTOH, the wrappers (shell script and this C one)
# are only useful if you want to execute the "real" binary.
# Since the "real" binary is built for $host, then this
# wrapper might as well be built for $host, too.
$opt_dry_run || {
$LTCC $LTCFLAGS -o $cwrapper $cwrappersource
$STRIP $cwrapper
}
As Ralf has pointed out, the comment above is not currently correct: we
currently do need to execute the binary wrapper, even if we don't want
to run the actual target, because the next step is:
# Now, create the wrapper script for func_source use:
$opt_dry_run || {
$cwrapper --lt-dump-script >
$func_ltwrapper_scriptname_result
}
=== emulator problem
(1) guard win32-isms in the binary wrapper source code against non-win32
build environment
(2) use build environment compiler to compile binary wrapper
(3) this means that you CAN'T use an emulator environment at all, if you
wanted to run the tests -- because the emulator won't be able to execute
the binary wrappers
Okay. So that's not really a solution. What we really need is the
capability to extract (or emit) the shell wrapper during the link phase
(or earlier), just so libtool can source it back in and parse the contents.
One important note: for win32 targets, there are TWO different copies
(with different names) of the shell wrapper. One is created during the
link phase, and is only present so that it can be sourced back in by
libtool and parsed. The other (ephemeral) copy is (re)created each time
the binary wrapper is executed, and the binary wrapper then execs it.
Our problem is the first one. How about, when cross-compiling for win32
targets, keep most things as they are (with perhaps some of the
line-ending changes described above). However, just change this bit:
# Now, create the wrapper script for func_source use:
func_ltwrapper_scriptname $cwrapper
$RM $func_ltwrapper_scriptname_result
trap "$RM $func_ltwrapper_scriptname_result; exit
$EXIT_FAILURE" 1 2 15
$opt_dry_run || {
$cwrapper --lt-dump-script >
$func_ltwrapper_scriptname_result
}
so that when cross-compiling for win32, we use the "normal" method of
creating $func_ltwrapper_scriptname_result -- direct creation from libtool:
func_emit_wrapper no > $func_ltwrapper_scriptname_result
Here's a possible (completely untested) patch.
--
Chuck
Index: ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.99
diff -u -r1.99 ltmain.m4sh
--- ltmain.m4sh 5 Mar 2008 20:14:43 - 1.99
+++ ltmain.m4sh 8 Mar 2008 18:54:53 -
@@ -2513,6 +2513,7 @@
#ifdef _MSC_VER
# include
# include
+# include
#else
# include
# include
@@ -2523,6 +2524,7 @@
#include
#include
#include
+#include
#include
#if defined(PATH_MAX)
@@ -2556,6 +2558,7 @@
#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
defined (__OS2__)
# define HAVE_DOS_BASED_FILE_SYSTEM
+# define FOPEN_WB "wb"
# ifndef DIR_SEPARATOR_2
# define DIR_SEPARATOR_2 '\\'
# endif
@@ -2577,6 +2580,17 @@
# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2)
#endif /* PATH_SEPARATOR_2 */
+#ifdef __CYGWIN__
+# define FOPEN_WB "wb"
+#endif
+
+#ifndef FOPEN_WB
+# define FOPEN_WB "w"
+#endif
+#ifndef _O_BINARY
+# define _O_BINARY 0
+#endif
+
#define XMA
Re: cross compilation to w32
Hi Gary, * Gary V. Vaughan wrote on Sat, Mar 08, 2008 at 05:39:38PM CET: > On 8 Mar 2008, at 07:03, Ralf Wildenhues wrote: >> we have a couple of problems wrt. cross compilation to w32 in 2.2. >> When I cross-compile from GNU/Linux to MinGW using Debian's mingw32 >> packages (i586-mingw32msvc-gcc etc.), then link mode already >> requires executing a host program; for example: [...] >> This means that building will fail on systems without a simulator. [...] >> Does anybody see easy ways out? > > Shouldn't the cwrapper be compiled with the host compiler? It looks as > though it isn't at the moment... It is. With our new scheme in 2.2 however, the wrapper is also *executed* already at link time, rather than only at run time. That is the gist of the first problem for users without a simulator. Cheers, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cross compilation to w32
Hallo Ralf, On 8 Mar 2008, at 07:03, Ralf Wildenhues wrote: we have a couple of problems wrt. cross compilation to w32 in 2.2. When I cross-compile from GNU/Linux to MinGW using Debian's mingw32 packages (i586-mingw32msvc-gcc etc.), then link mode already requires executing a host program; for example: cd tests/demo /bin/sh -x ./libtool --tag=CC --mode=link i586-mingw32msvc-gcc -g -O2 -export-dynamic -dlpreopen libhello.la -L/usr/i586-mingw32msvc/ lib -o helldl.exe dlmain.o [...] + ./helldl.exe --lt-dump-script Wine exited with a successful status + exit 0 This means that building will fail on systems without a simulator. The other problem I've stumbled over so far is this one: the *_ltshwrapper file has DOS line endings. This causes 'make install' to fail, because the native /bin/sh cannot parse the script: /bin/sh ./libtool --mode=install /usr/bin/install -c 'hell.exe' '/ home/ralf/download/cvs/libtool/HEAD/build-mingw/_inst/bin/hell.exe' : command not foundapper: line 2: : command not foundapper: line 11: : command not foundapper: line 16: ./.libs/hell_ltshwrapper: line 26: syntax error near unexpected token `newline' ./.libs/hell_ltshwrapper: line 26: ` case `(set -o) 2>/dev/null` in *posix*) se' -o posix;; esac libtool: install: invalid libtool wrapper script `./.libs/ hell_ltshwrapper' Does anybody see easy ways out? Shouldn't the cwrapper be compiled with the host compiler? It looks as though it isn't at the moment... Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
