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 (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 So, the above sequence 1) sucks, and 2) is probably not the way smarter people would do it. But, I got it up and running in under a day, so that does meet at least some basic requirements. I put most of that in a shell script that I can send you to at least illustrate the configure options at each step, and other details. I guess I should check all this in to mingw-w64's repos. Note that there are a LOT of testsuite failures. There was a time in the 4.4 era when Kai and I (let's be honest, it was 90% him) worked it down to < 20 failures across all languages. That is no longer the case, so we are trying once again to get the failure count down. On that note, Jon (W), it's interesting to hear that you regularly run the libstdc++ testsuite under wine. 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? 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 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. 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?
