bug-libtool
[Top][All Lists]
Advanced

[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



reply via email to

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