[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #9341] testsuite.at: prefer diff --strip-trailing-cr
From: |
Peter Rosin |
Subject: |
Re: [patch #9341] testsuite.at: prefer diff --strip-trailing-cr |
Date: |
Tue, 16 May 2017 09:49:04 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 2017-05-10 16:24, Michael Haubenwallner wrote:
> URL:
> <http://savannah.gnu.org/patch/?9341>
>
> Summary: testsuite.at: prefer diff --strip-trailing-cr
> Project: GNU Libtool
> Submitted by: haubi
> Submitted on: Wed 10 May 2017 04:24:08 PM CEST
> Category: None
> Priority: 5 - Normal
> Status: None
> Privacy: Public
> Assigned to: None
> Originator Email:
> Open/Closed: Open
> Discussion Lock: Any
>
> _______________________________________________________
>
> Details:
>
> On Cygwin, when using CC=cl.exe (MSVC) as the compiler, some test cases fail
> just because of unexpected carriage return output from test binaries.
>
> Fortunately, with GNU diff there is the --strip-trailing-cr flag, which allows
> to easily get the libtool test suite agnostic to CR, independent of any host
> triplet used:
>
> If 'diff --help' tells about the --strip-trailing-cr flag, attached patch does
> wrap the host diff command to add that flag for when run as 'diff -u' via
> $at_diff in the test suite, in addition to stop adding CR to expected output
> files for mingw.
>
> This allows to succeed following test cases when run on Cygwin with MSVC
> environment and these configure options: CC=cl CXX="cl /TP" GCJ=no GOC=no
> F77=no FC=no NM=no CFLAGS= CXXFLAGS=
>
> 27: link against a preloaded static library
> 30: deplibs_check_method
> 40: build and link against a static library
> 41: build and link against a dynamic library
> 42: build both static and dynamic
> 43: allow_undefined_flag
> 49: static library interdependencies
> 112: dlloader API
I think these testsuite problems goes away if you configure with something
like ".../configure --build=i686-pc-cygwin --host=mingw32" as indicated in
the manual [1]. Or maybe it's x86_64-pc-cygwin in your case?
The rationale is that when Cygwin is used to drive a MSVC build, I have
considered it a Cygwin to MinGW cross, because that is much closer to the
truth than a native Cygwin build (which is what is assumed if you just
override CC).
But I haven't tested recently, YMMV...
Cheers,
Peter
[1]
https://www.gnu.org/software/libtool/manual/libtool.html#Cygwin-to-MinGW-Cross