On Wed, 25 Aug 2021, 03:37 NightStrike, <nightstr...@gmail.com> wrote:
> On Tue, Aug 24, 2021 at 8:48 AM David Malcolm <dmalc...@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). >
