libtool-patches
[Top][All Lists]
Advanced

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

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


From: Charles Wilson
Subject: Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Date: Wed, 25 Aug 2010 00:10:58 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

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



reply via email to

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