[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool 2.4 cygwin test failure log
From: |
Charles Wilson |
Subject: |
Re: libtool 2.4 cygwin test failure log |
Date: |
Sat, 22 Jan 2011 13:24:39 -0500 |
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 1/21/2011 3:49 PM, Scott L wrote:
> NUM: FILE-NAME:LINE TEST-GROUP-NAME
> KEYWORDS
>
> 38: link-order.at:26 Link order test
> libtool
> 43: static.at:68 static linking flags for programs
> libtool interactive
> 51: execute-mode.at:25 execute mode
> libtool
> 112: cmdline_wrap.at:28 Run tests with low max_cmd_len
> recursive
There are a few failures in "stock" libtool 2.4 that are fixed in the
cygwin releases:
114 tests behaved as expected.
10 tests were skipped.
Mostly, these are because the cygwin release has some short-term "good
enough" patches that are NOT "good enough" for the upstream libtool,
which is waiting on better, or more thorough, solutions.
I'm thinking specifically of #43, where the problem boils down to
libtool not passing --static-libstc++ --static-libgcc thru to the
compiler. Cygwin's libtool hacks around that, but the desired "real"
solution is for libtool itself to stop:
1) trying to figure out how to call ld directly, and therefore
memorizing all the tiny little details each language driver already
takes care of
2) and instead simply use the appropriate language driver to perform
the link (obviously, this is for the GNU toolchain only)
But...that's a big project, and is probably a libtool-2.6 or -3.0
project, and nobody has had time to pursue it. Hence...#43 is still
broken on cygwin in "stock" libtool, and cygwin's version has a hackish
workaround.
Short answer: I don't think these errors will be fixed in "stock"
libtool without a lot of work.
--
Chuck