libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] [cygwin|mingw|cross-compile]: Path conversion support.


From: Charles Wilson
Subject: Re: [PATCH] [cygwin|mingw|cross-compile]: Path conversion support.
Date: Wed, 08 Sep 2010 18:55:49 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3

On 7/18/2010 9:07 PM, Charles Wilson wrote:
> linux->cygwin cross:
> ====================
> old: 2 of 112 tests failed (12 tests were not run)
>       FAIL: tests/demo-hardcode.test
>       FAIL: tests/depdemo-relink.test
> new: AWFUL again -- but there's an explanation
>      88 tests were run, 28 failed (3 expected failures).
>      29 tests were skipped.
> I was using my new, sysroot-less linux->cygwin cross compiler, so
> I expected "good" results just like the last time I used this compiler.
> However, UNLIKE last time, I went ahead an set LT_CYGPATH to point to
> my wine/cygwin cygpath.exe.  Well, as has been demonstrated, it coredumps
> a lot -- and prints lots of gobbledygook.  The new testsuite doesn't like
> gobbledygook.  LAST time, I left LT_CYGPATH unset, so libtool simply
> skipped that part of the test.
> 
> I'll re-run again, without LT_CYGPATH set, just to be sure...

FWIW, ensuring LT_CYGPATH is not set doesn't actually make the testsuite
performance any better.  You have to actually turn off binfmt.  Here's why:

m4_define([LT_AT_EXEC_CHECK],
[lt_exe=$1; if test -f "$1$EXEEXT"; then lt_exe=$lt_exe$EXEEXT; fi
AT_CHECK([if "$lt_exe" $5; then :; else lt_status=$?; ]dnl
         [  m4_ifval([$2], [test $lt_status != $2 && ])]dnl
         [  test "X$host" != "X$build" && test -x "$lt_exe" && exit 77; ]dnl
         [  exit $lt_status; fi],[$2],[$3],[$4])
])


The way LT_AT_EXEC_CHECK works is:
   * ALWAYS try to run the executable
       if it passes, great
   *   otherwise, compare the exit status with a provided value
          if it matches the expected value, great
   *      otherwise, if crossbuilding and the exe exists and is
             marked executable, then
   *         at least building the app succeeded: SKIP
   *         otherwise, return with the exit status of the app

The problem occurs because with cygwin-1.7 + Wine, running apps (almost)
always fails, but Wine itself returns a successful error code. But...the
stdout/stderr values are definitely NOT what the test which CALLED
LT_AT_EXEC_CHECK expects.

The only way I've found to make this "work" is to turn off binfmt, so
that Wine is NOT used to launch the cygwin exe -- linux tries to run the
.exe itself.  This, of course, fails...and that allows the 'if
crossbuilding' clause to kick in, and the test is marked SKIP.

Note that this is already documented in the recent changes to
libtool.texi -- I just hadn't spelled it out in a message to this list,
and I'd promised to post the best-case linux->cygwin test results, so...

However, LT_AT_EXEC_CHECK *is* doing the right thing here.  We *want* to
first try to run the (possibly foreign) $host executable.  What if
$build=x86_64-pc-linux-gnu and $host=i686-pc-linux-gnu?  That should
work, and we shouldn't just assume it won't and automatically SKIP.  Or
better yet, $build=i686- vs. $host=i386-?

I think this is a Wine bug; I'll report it upstream.  But for now...on
the linux->cygwin case, I'll always be reporting testsuite results with
binfmt disabled.

And linux->mingw results with binfmt enabled...


linux->cygwin:
==============
old testsuite: 2 of 114 tests failed (10 tests were not run)
        FAIL: tests/demo-hardcode.test
        FAIL: tests/demo-relink.test
demo-relink should be marked SKIP if cross compiling
I don't really know why demo-hardcode failed; I don't think hardcoding
is supported in PE/COFF executables, so what gives?

demo-hardcode.test: ===  Finding libtool.m4's guesses at hardcoding values
= Searching for hardcoded library directories in each program
.libs was not hardcoded in `hc-direct', as libtool expected
.libs was not hardcoded in `hc-libflag', which fooled libtool
`hc-libpath' was not linked properly, as libtool expected
.libs was not hardcoded in `hc-minusL', as libtool expected


I think this is wrong, for both cygwin and mingw:
        hardcode_libdir_flag_spec="-L\$libdir"
-L just sets the search path during linking, and has nothing to do with
a runtime-hardcoded path. For reference, native linux (ELF) has this:
        hardcode_libdir_flag_spec="\${wl}-rpath \${wl}\$libdir"



new testsuite:
        ERROR: 63 tests were run,
        4 failed (2 expected failures).
        57 tests were skipped.
The two unexpected failures were:
 38: Link order test                  FAILED (link-order.at:121)
112: Run tests with low max_cmd_len   FAILED (cmdline_wrap.at:43)


38 seems to be an oversight in the sysroot support, but I haven't
thought about it too much:

libtool: link: warning: library
`/home/me/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/liba.la'
was moved.
libtool: link: cannot find the library
`/opt/devel/cygwin/i686-pc-cygwin/sys-root/home/me/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/libb.la'
or unhandled argument
`=/home/cwilson/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/libb.la'

Note that it's expecting my entire build area to have been relocated
underneath my compiler's sysroot.  This may actually be correct, given
the design of the sysroot support, but just that this particular test
can't be performed in a cross+sysroot environment -- in which case (this
portion of) this test suite be skipped in cross(+sysroot?).


112 fails because 38 does.

--
Chuck



reply via email to

[Prev in Thread] Current Thread [Next in Thread]