[patch #9341] testsuite.at: prefer diff --strip-trailing-cr

[Michael Haubenwallner]

Follow-up Comment #2, patch #9341 (project libtool):

Then I'm wondering why libtool does actually support the cc_basename=cl with
host_os=cygwin at all.

Anyway, my final goal is beyond the MSVC toolchain: I'm about to rework the
old patches
(http://lists.gnu.org/archive/html/libtool-patches/2008-02/msg00014.html)
adding support for the MSVC wrapper called "Parity" (at
https://github.com/haubi/parity/ for now), which does:
* not require specific environment variables for MSVC, but can find MSVC from
the Registry
* convert Unix to Windows path names as necessary
* provide GCC like commandline options
* provide gcc3-style dependency tracking
* set up the final binary's std-stream mode to O_BINARY
* provide some additional system headers (stdint.h, dlfcn.h, ...)
* emulate some runtime loader features, on Linux known as embedded runpath,
embedded soname, LD_BIND_NOW, LD_LIBRARY_PATH, LD_PRELOAD
* probably more

We do use it on Cygwin (now, since Interix is gone) within Gentoo Prefix, to
maintain an ecosystem using the native MSVC toolchain, configured in the
"lying" way with --build=i586-pc-winnt --host=i586-pc-winnt - which is similar
to "multilib" actually.

That is, I'm about to prepare libtool patches to support the *-*-winnt host
triplet, which feels a lot more correct for MSVC than using --host=mingw32 -
and should support unwrapped cl.exe as well.

But as the application's O_BINARY setting may vary for host_os=winnt then, I
prefer to 'diff --strip-trailing-cr' rather than testing for another host_os -
or even current binary setting.

Thus the idea is to have the testsuite setup not depend on $host_os, but just
ignore CR if possible - as the test programs all have textual output only.

Thanks!
/haubi/

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[patch #9341] testsuite.at: prefer diff --strip-trailing-cr

[Peter Rosin]

Follow-up Comment #1, patch #9341 (project libtool):

[copying my msg from the ML to the patch tracker]

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


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [patch #9341] testsuite.at: prefer diff --strip-trailing-cr

[Peter Rosin]

On 2017-05-10 16:24, Michael Haubenwallner wrote:
> URL:
>   
> 
>  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

[patch #9349] libtool.m4: For MS dumpbin drop CR first.

[Michael Haubenwallner]

URL:
  

 Summary: libtool.m4: For MS dumpbin drop CR first.
 Project: GNU Libtool
Submitted by: haubi
Submitted on: Tue 16 May 2017 08:46:49 AM CEST
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

On Cygwin, gawk-4.1.4-3 and newer do not treat the input stream as text any
more, leaving libtool behind with carriage return in symbol names.

Upstream gawk commit is:
http://git.savannah.gnu.org/cgit/gawk.git/commit/?id=5db38f775d9ba239e125d81dff2010a2ddacb48e

These tests switch back from FAILED to ok with MSVC and gawk-4.1.4-3 on
Cygwin:
 28: build and dynamically load a module
 29: preload static and dynamic module
 31: disable fast install
 32: force PIC objects
 34: hardcoding library path
 36: uninstalled libraries have priority
 37: linking with long file names

Thanks!
/haubi/



___

File Attachments:


---
Date: Tue 16 May 2017 08:46:49 AM CEST  Name:
0001-libtool.m4-For-MS-dumpbin-drop-CR-first.patch  Size: 1kB   By: haubi



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/