[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Analyzer tests fail on windows
From:       Jonathan Wakely via Gcc <gcc () gcc ! gnu ! org>
Date:       2021-08-25 9:37:05
Message-ID: CAH6eHdTCZH1B3kJyZr5M4XFV-5z4JYhPhZw=EMS5h4Z0B1HKzw () mail ! gmail ! com
[Download RAW message or body]

On Wed, 25 Aug 2021, 03:37 NightStrike, <nightstrike@gmail.com> wrote:

> On Tue, Aug 24, 2021 at 8:48 AM David Malcolm <dmalcolm@redhat.com> wrote:
> > Thanks for working through the above.
> >
> > Do you have an account in GCC's bugzilla?  If so, please can you turn
> > this into a bug report there.  Is there a recipe for testing this via
> > wine?  (it's been almost 20 years since I did any Windows coding...)
> >
> > Dave
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102052
>
> The method I'm using to test this is convoluted and difficult to set
> up.  Based on his parallel reply to this thread, Jon might have a test
> setup that works better (and more professionally) with an internal
> redhat environment


I just use my personal fedora box for this.


(W, not Y, obvoiusly :) )
>
> What I did, though, was all on CentOS 6, which in itself needs newer
> tools, but not many.
>
> 1) Build a modern native compiler with binutils installed to the same
> prefix.  For my test I used 11.2.0 and 2.37.
> 2) Build the cross compiler (note: for steps c and f, I needed to
> include dejagnu in the source tree b/c it wasn't available for me)
>   a) Make a new sysroot with a mingw symlink to the target
> x86_64-w64-mingw32
>   b) Build the mingw-w64 headers, install into the sysroot
>   c) Build binutils, install into the sysroot
>   d) Build part of gcc, use the all-gcc target
>   e) Build the mingw-w64 crt using the result of (d), install to sysroot
>   f) Build the rest of gcc (use the normal all target), install to sysroot
> 3) Use the native compiler to build a modern bison (I used 3.something)
> 4) Use (1), (2), and (3) to build a stripped down wine with most
> features disabled (like any GUI features, for instance)
> 5) Use a new wine prefix with debug disabled and a custom dejagnu
> board that uses wine as the driver



I just use the mingw-w64 binutils and sysroot installed by the Fedora
mingw-w64 cross compiler, and copy some of the options from the configure
command use to build that Fedora compiler. I also use the Fedora Wine
packages. Fedora provides everything I need to be able to build+test my
libstdc++ changes before I push them upstream.


On that note, Jon (W), it's interesting to hear that you regularly run

the libstdc++ testsuite under wine.


I wouldn't say I do it regularly, only when changing std::filesystem code,
because that has a lot of Windows-specific #if code that I can't test
otherwise. I generally only run the filesystem tests this way.


  I'd like to compare my results to
> yours to see if my environment is just completely bogus.  Are your
> results on the testresults mailing list?


No, sorry, I don't submit them (because I only run a fraction of the tests).


I haven't started with g++
> yet, though, as it's harder to run, and I figured that gcc should pass
> first.  I have one question, though, that perhaps you can answer
> upfront.  After you do a build, before you run make check, what do you
> do to make the dll's available to the testsuite?  Do you set WINEPATH
> to include their location, do you copy them somewhere first, do you
> make install first, or is there maybe a RUNTESTFLAGS option?  I was
> struggling with this part, as no fix seemed to work permanently.
>

I don't run make check, I use a shell script of my own devising which
handles a small subset of { dg-* } directives, and links statically to
avoid needing to find DLLs. It's a hack, but it does just enough for my
needs.



> > I use this for running libstdc++ tests under Wine:
> >
> > Xvfb :9 -screen 0 1024x768x16 &
> > trap 'kill %1' EXIT
> > # Start wine on the dummy X server, running a simple program.
> > # This means that each "wine a.exe" below won't start wine again.
> > DISPLAY=:9.0 WINEDEBUG=fixme-all wine view.exe &
> > trap 'kill -INT %2 && sleep 2 && kill -INT %1' EXIT
> >
> > and then "WINEDEBUG=fixme-font wine a.exe" to run an executable a.exe
> > built by a mingw-w64 cross compiler.
>
> Also, note that there's a command line option to wineserver to
> automate backgrounding it to avoid the workaround you are using.  I
> haven't tried it, though, but I can let you know if I can get it to
> work.


I'd be interested in that. My approach was just cobbled together by trial
and error.


  You are right that there is non-trivial overhead in starting
> wine each time.  For my WINEDEBUG, I use "=-all" to shut everything
> off.  Maybe that's a bad idea.  Thoughts?
>

I just used enough to silence some irrelevant warnings. There do seem to be
more warnings from the latest Wine so maybe I should just use -all (I don't
think I've ever seen one of those warnings that was relevant to my testing,
or that I could do anything about).

>
[prev in list] [next in list] [prev in thread] [next in thread]