Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

[Charles Wilson]

On 8/26/2010 5:20 PM, Charles Wilson wrote:
> On 8/26/2010 4:18 PM, Ralf Wildenhues wrote:
>>> mingw-native (e.g. msys->mingw)
>>
>> This is interesting.  I don't see these mdemo*exec failures in my
>> mingw-native setup.  I wonder why that is.  When parallel-tests is
>> merged, we should look at test-suite.log.
>
> I still have all the separate build envs. I can take a look, the "old
> way" even without parallel-tests support.  Will post later.

It appears the problem is that the mdemo{2}_static.exe tests don't work,
when mdemo{2}-conf.test is used.  They DO work when mdemo-static.test is
used (there is no mdemo2-static.test).

Now, this is a little disturbing, since my -dlpreopen was supposed to
have fixed this; I'm pretty sure it DID, so it looks like something
bitrotted, at least on mingw native, as *I* am building it (I'm using
mingw gcc-4.4.0, not the older 3.4.x gcc).  However, the symbol names
are not mangled; there aren't a bunch of gobbledy-gook DLL symbols (or
worse, __imp_ symbols from .dll.a) being pulled in to the LTX array for
mdemo_static, so at least THAT part of my -dlpreopen is still working as
intended.

I rebuilt each, with RM=: so the temp files were saved. I put the
results here:
http://libtool.cwilson.fastmail.fm/conf-mdemo.tar.xz
http://libtool.cwilson.fastmail.fm/static-mdemo.tar.xz

An interesting item:
--- static/mdemo/.libs/mdemo_static.exeS.c
+++ conf/mdemo/.libs/mdemo_static.exeS.c
@@ -11,7 +11,6 @@

 /* External symbol declarations for the compiler. */
 extern int _foo1_helper();
-extern int _foo2_helper();
 extern int foo1_LTX_foo1();
 extern int foo1_LTX_hello();
 extern char foo1_LTX_nothing;
@@ -45,19 +44,18 @@
   {"myvar", (void *) &myvar},
   {"test_dl", (void *) &test_dl},
   {"test_dlself", (void *) &test_dlself},
-  {"foo1.a", (void *) 0},
-  {"_foo1_helper", (void *) &_foo1_helper},
-  {"foo1_LTX_foo1", (void *) &foo1_LTX_foo1},
-  {"foo1_LTX_hello", (void *) &foo1_LTX_hello},
+  {"foo1.dll", (void *) 0},
   {"foo1_LTX_nothing", (void *) &foo1_LTX_nothing},
-  {"libsub.a", (void *) 0},
+  {"foo1_LTX_hello", (void *) &foo1_LTX_hello},
+  {"foo1_LTX_foo1", (void *) &foo1_LTX_foo1},
+  {"_foo1_helper", (void *) &_foo1_helper},
+  {"libsub-0.dll", (void *) 0},
   {"sub", (void *) &sub},
-  {"libfoo2.a", (void *) 0},
-  {"_foo2_helper", (void *) &_foo2_helper},
-  {"libfoo2_LTX_foo2", (void *) &libfoo2_LTX_foo2},
-  {"libfoo2_LTX_hello", (void *) &libfoo2_LTX_hello},
+  {"libfoo2-0.dll", (void *) 0},
   {"libfoo2_LTX_nothing", (void *) &libfoo2_LTX_nothing},
-  {"libsub.a", (void *) 0},
+  {"libfoo2_LTX_hello", (void *) &libfoo2_LTX_hello},
+  {"libfoo2_LTX_foo2", (void *) &libfoo2_LTX_foo2},
+  {"libsub-0.dll", (void *) 0},
   {"sub", (void *) &sub},
   {0, (void *) 0}
 };

So...there's obviously something here that needs to be fixed, but it's
not a regression caused by THIS patch, since I get the same results with
and without it.

Note that I do not get similar behavior on cygwin, because cygwin
doesn't use this same code path. Unlike mingw, it has "dlopen_self=yes"
whereas mingw is "dlopen_self=unknown".

>>> 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.
>>
>> Whether or not, it'd be interesting to see verbose logs of these at some
>> point.
> 
> They aren't. I have the logs; will post separately later.

Attached. For demo-hardcode, the error message was:
= 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
FAIL: tests/demo-hardcode.test

I'm pretty sure this doesn't have anything to do with THIS patch
(especially as it is not a regression; same results both with and
without this patch).


For depdemo-relink, the error was:
depdemo-relink.test: ===  running depdemo/depdemo with broken libl3.la
...err, huh?  This is a cross compile, and this test should PROBABLY be
skipped.  However, since it is NOT skipped, then we go ahead and execute
it (and, since I have binfmt enabled, wine is used).

Now, the "expected" behavior of this test, on win32, is to generate an
"application failed to initialize" popup, since the DLL can't be found.
However, wine behaves differently than "real" win32 when you try to
generate a popup (e.g. the evil "Failed to start" popup) but don't have
an X server connection: due to what appears to be a wine bug, wine
itself coredumps and prints a lot of diagnostic information.

This is not what the libtool test suite expects, so..."FAIL".

The real bug here is that the relink tests (both of them, actually)
should be skipped when cross-compiling, because you have no business
trying to execute the $host executable.

>>> 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.
>>
>> Ditto.
> 
> See below.
> 
>>> 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.
>>
>> OK, so we have to ignore results from this configuration as long as that
>> issue is not fixed.
> 
> Well, as it turns out (see my other message in this thread) it appears
> my linux->cygwin cross compiler is borked.  So, I need to re-do THAT and
> make sure it is working first.

Okay, so I rebuilt my linux->cygwin compiler after asking for help on
address@hidden  This one does NOT have sysroot support (one thing at a
time...) but it DOES work.  I was able to build not just hello world in
C++, but also to rebuild cygwin itself, and the new DLL worked fine.

So, re-running the linux->cygwin tests, I got:
linux->cygwin (old tests): 2 of 91 FAIL, 33 SKIP
        FAIL: tests/demo-hardcode.test
        FAIL: tests/demo-relink.test
linux->cygwin (new tests): 59 as expected. 58 skipped.

Three notes:
1) With *this* compiler, there are no regressions with this patch.  I
got the same results both with and without this patch.

2) The failures on linux->cygwin in the old testsuite are similar to the
failures on linux->mingw in the old testsuite (not the same;
linux->mingw fails depdemo-relink; linux->cygwin fails demo-relink).

3) EVERY new test that FAILED when using my "broken" compiler was
actually SKIPPED when using the new working one.  So, oddly, with the
broken compiler, the testsuite seems to be confused as to whether the
build is a crossbuild or not.

However, I won't be looking in to this further until after I rebuild my
toolchain (again) with sysroot support; probably next week.

> That doesn't change the fact that cgywin-1.7+wine == fail. So... :-(

...and this statement is still true.


So, to sum up all of these test runs: it does not appear that ANY of the
failures experienced are regressions, or are due to anything associated
with THIS patch, on any of the platforms or configurations I have tested.

I still need to do the "cygwin->mingw (lie)" case, but I think I will
save that until after I resolve the code comments.

--
Chuck

demo-hardcode.log
Description: Text document

depdemo-relink.log
Description: Text document