libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.


From: Peter Rosin
Subject: Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.
Date: Thu, 09 Sep 2010 11:47:13 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Den 2010-09-09 00:19 skrev Charles Wilson:
> On 9/8/2010 6:14 PM, Charles Wilson wrote:
>> On 9/8/2010 5:52 PM, Peter Rosin wrote:
> 
>>> sharedlib_from_linklib_cmd, which is not used anywhere according
>                          ^^^^
>>         # no lafile. user explicitly requested -dlpreopen <import library>.
>>         $sharedlib_from_linklib "$dlprefile"
>                                  ^
> Looks like something got dropped somewhere.
> 
>> (However, there is an unfixed bug here; apparently something has changed
>> in libtool between when this patch was created, and when it was
>> committed, such that the static lib part no longer works properly; this
>> is why on cygwin and mingw the mdemo-exec tests STILL fail.  Very
>> frustrating.  I plan to track this down in the next day or so).

I have these results on Cygwin:

PASS: tests/mdemo-conf.test
PASS: tests/mdemo-make.test
PASS: tests/mdemo-exec.test
PASS: tests/mdemo-inst.test
PASS: tests/mdemo-unst.test
PASS: tests/mdemo-dryrun.test

> Hmm...I wonder...is this the cause of the mdemo-exec regression?  I
> don't THINK so, because that testcase uses the .la files and not the
> .dll.a ones IIRC, but it should probably be fixed regardless.  I'll find
> out...

The missing _cmd typo is not the cause.

Hmmm, the issue is somewhat clouded by the fact that tests/defs.m4sh
has this in func_exec:

    test -n "$my_exp_output" \
      && my_exp_output="| $EGREP -e "\""$my_exp_output"\"

    if eval $my_program $my_exp_output; then :

which basically ignores the exit code of $my_program whenever
$EGREP finds what it's looking for. Which it does when this is
executed (first func_exec in mdemo-exec.test):

  tests/mdemo/mdemo_static.exe tests/mdemo/foo1.la tests/mdemo/libfoo2.la

But since no grep is requested when this is executed (third func_exec
in mdemo-exec.test):

  tests/mdemo/mdemo_static.exe \
    /c/cygwin/home/peda/libtool/git/mingw/tests/mdemo/foo1.la \
    /c/cygwin/home/peda/libtool/git/mingw/tests/mdemo/libfoo2.la

that failure isn't masked. I wonder how many more failures are masked this
way?

Anyway, both fail in pretty much the same way for me:

can't open the module tests/mdemo/foo1.la!
error was: The specified module could not be found.
can't open the module tests/mdemo/foo1!
error was: The specified module could not be found.
can't open the module tests/mdemo/libfoo2.la!
error was: The specified module could not be found.
can't open the module tests/mdemo/libfoo2!
error was: The specified module could not be found.

can't open the module c:/cygwin/home/peda/libtool/git/mingw/tests/mdemo/foo1.la!
error was: The specified module could not be found.
can't open the module c:/cygwin/home/peda/libtool/git/mingw/tests/mdemo/foo1!
error was: The specified module could not be found.
can't open the module 
c:/cygwin/home/peda/libtool/git/mingw/tests/mdemo/libfoo2.la!
error was: The specified module could not be found.
can't open the module c:/cygwin/home/peda/libtool/git/mingw/tests/mdemo/libfoo2!
error was: The specified module could not be found.

Still hunting...

Cheers,
Peter



reply via email to

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