Re: use $EXEEXT consistently in new testsuite

[Ralf Wildenhues]

Hi Roumen,

* Roumen Petrov wrote on Wed, Nov 26, 2008 at 12:46:00AM CET:
> I will check this failure:
> 28: Runpath in libtool library files                FAILED  
> (runpath-in-lalib.at:59)

Please post tests/testsuite.log, so we can see the verbose failure
output.  You can also run
  make check-local TESTSUITEFLAGS='-v -d -x 28'

for mostly the same information (-x adds tracing output).

Interestingly, I don't see this failure on a linux->mingw cross.
Maybe you worked from the tree from Sunday?  I overlooked one EXEEXT
instance in runpath-in-lalib.at there, fixed on Monday.

> The other not "ok" test:
>  21: F77 convenience archives   skipped (convenience.at:110)
>  22: FC convenience archives    skipped (convenience.at:170)
>  23: Java convenience archives  skipped (convenience.at:267)
> It is time to install those tools :( ;)

Well, if you don't have them, don't worry.

>  29: static linking flags for programs skipped (static.at:177)

Yes, I've seen this one as well with a linux->mingw cross.

>  35: static library contains static library   expected failure  
> (archive-in-archive.at:49)
>  68: build tree relpaths                      expected failure 
> (deplibs-ident.at:68)

These two are known bugs in Libtool.  They are not system-specific.

>  74: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43)
> Still no time to look into this one.

This is a followup failure of 28 above.  The max_cmd_len test reruns
some of the previous tests, but with a modified libtool script that
simulates a low command line length limit.  That way, we can exercise
some code paths that deal with many objects so the resulting commands
don't fit in one command line.  So if 28 fails, this one should fail,
too.  Don't worry about it until 28 is fixed.

Cheers,
Ralf