January 2013 - Wine-Devel - list.winehq.org

Re: [wine-devel] Re: [SOLVED] wine-1.5.20 regression compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

by Alan W. Irwin

On 2012-12-28 10:22-0800 Alan W. Irwin wrote: > [...Let's] leave > it like this. Wine-1.5.20 has introduced an obvious regression for an > important Windows app (the MinGW gcc compiler for Windows) that has > been working for years for prior Wine versions. Grant communicated to me off list that he was able to replicate the regression for Wine-1.5.20, but he also found (as did Boyd) the regression had (inadvertently?) been solved for a recent wine-git version. Grant's results were for MinGW-4.7.2. I have just now confirmed for MinGW-4.7.0 that Wine-1.5.20 had the issue, but wine-1.5.20-104-g0004788 (or one of the 103 commits before that) solves it. So although using the Wine platform to build software doesn't work for Wine-1.5.20, building and testing software (notably shapelib, PLplot, ephcom, and te_gen using cmake.exe/MinGW/MSYS) works well for 1.5.19, and from my simple test of gcc for recent Wine git, it is certainly looking good for the next Wine release as well! Grant also told me that gcc had no obvious issues for wine-1.5.20 when invoked directly with wine. Instead he had to follow my wineconsole + bash method for invoking gcc to confirm the issue for wine-1.5.20. The following is my recipe for that gcc invocation method if anyone here wants to bisect to find the commit between 1.5.19 and 1.5.20 that created the issue, and the commit between 1.5.20 and wine-1.5.20-104-g0004788 that solved it: (1) Download and install a recent MinGW/MSYS using the automatic installer, mingw-get-inst-20120426.exe that is accessible at https://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw…. Check the GUI box to get the latest versions. Some time ago I installed 4.7.0 this way, and Grant's experience is that now installs 4.7.2. Include MSYS in the install, and install to a unique prefix (rather than a wine system file location). (I did that to make sure I could easily change between wine versions using different PATH and WINEPREFIX values.) (2) Make a bash "source" script to set up the PATH so that wine can find MinGW and MSYS where you installed them in the above step. Here is my version of that script: irwin(a)raven> cat set_mingw_msys_path.wine_sh export MINGW_VERSION=4.7.0 MINGW_PREFIX=/z/home/wine/newstart/MinGW_$MINGW_VERSION PATH=$MINGW_PREFIX/msys/1.0/bin/:$PATH PATH=$MINGW_PREFIX/bin/:$PATH (3) Get into a wineconsole environment wineserver -p wineconsole --backend=curses MinGW_4.7.0/msys/1.0/bin/bash.exe (4) Attempt to compile a "hello-world" programme from that environment bash.exe-3.1$ source set_mingw_msys_path.wine_sh bash.exe-3.1$ gcc hello_world.c On wine-1.5.20, this immediately creates an GUI error box. When you exit from that error box, a very long error message is displayed in the wineconsole terminal. In contrast to this bad behaviour of gcc on wine-1.5.20, for both wine-1.5.19 and wine-1.5.20-104-g0004788 this simple test compilation succeeds without issues and you can then run the resulting executable with bash.exe-3.1$ ./a.exe Hello World And now back to getting my forthcoming releases of ephcom and te_gen out the door this next weekend. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Jan. 2, 2013

Re: [PATCH] ntdll/tests: Fix SYSTEM_CACHE_INFORMATION failures [try 2]

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23718 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Jan. 2, 2013

Re: [PATCH] ntdll/tests: Fix SYSTEM_CACHE_INFORMATION failures on WIN64

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23712 Your paranoid android. === W2KPROSP4 (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) === WXPPROSP3 (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) === W2K3R2SESP2 (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) === WVISTAADM (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) info.c:556: Test failed: 0: got 0xc0000004 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) === W2K8SE (32 bit info) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation === W7PRO (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) info.c:556: Test failed: 0: got 0xc0000004 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36)

Jan. 2, 2013

Re: [3/4] windowscodecs: Implement CreateBitmapFromMemory.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23710 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Jan. 2, 2013

Re: [2/4] windowscodecs: Test whether CreateBitmapFromMemory stride is stored.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23709 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Jan. 2, 2013

Re: [PATCH] winebuild: Use Clang to assemble if its integrated assembler is being used.

by Charles Davis

On Jan 2, 2013, at 11:23 AM, Per Johansson wrote: > On Wed, Jan 2, 2013 at 5:05 PM, André Hentschel <nerv(a)dawncrow.de> wrote: >> >> Not sure if you can do it like that, as i understand it winebuild should always be able to crosscompile something, these ifdefs would destroy that feature. Only on Mac OS :). > > I suppose the correct way is to always use clang without target_alias > prefix, But Clang actually supports target triple prefixes. I'll just avoid passing $CC to winebuild and make it invoke Clang directly instead. Chip

Jan. 2, 2013

Re: [website] Are we doing something wrong with our secure connections?

by Juan Lang

Hi André, On Wed, Jan 2, 2013 at 8:08 AM, André Hentschel <nerv(a)dawncrow.de> wrote: > Hi, > FWIW i have just seen: > > > https://www.ssllabs.com/ssltest/analyze.html?d=testbot.winehq.org&hideResul… > > https://www.ssllabs.com/ssltest/analyze.html?d=test.winehq.org&hideResults=… > > https://www.ssllabs.com/ssltest/analyze.html?d=winehq.org&hideResults=on&ig… > > which tells me we have some problems with secure website connection, the > question is, do we need more security here? > The answer is, no. More reasoning: in general, I don't think we're relying on any confidentiality in the patches we submit to testbot: anyone can connect and see the patches, as well as their test results. So no, I don't think problems with TLS on testbot are a concern, now or ever. And in particular: the qualsys scan tells us that the cert we're using is vulnerable to the BEAST attack, and that the server is vulnerable to the CRIME attack. The BEAST and CRIME attacks can allow an attacker to learn the plaintext of a stable piece of ciphertext sent in many connections, e.g. an authentication cookie, without having learned the server's private key. In testbot's case, we do use cookie-based authentication after initial login, but at worst that'd allow an attacker to submit jobs as one of us developers, or cancel one of our test jobs, change our password, etc. I don't think this is much of a concern. --Juan

Jan. 2, 2013

Re: winebuild: Add configure option to use llvm-mc as assembler.

by Charles Davis

On Jan 2, 2013, at 5:35 AM, Per Johansson wrote: > On Wed, Jan 2, 2013 at 3:12 AM, Charles Davis <cdavis5x(a)gmail.com> wrote: > >> What kind of undefined symbol errors? Other than the ones I got because as(1) from cctools can't grok CFI pseudo-ops (and probably never will because of Clang), I don't know of any symbol problems building Wine with Clang on Mac OS. Might have something to do with my system version (I'm still on 10.6, and I probably won't move until I find some way to run -arch ppc apps since Apple gutted Rosetta from 10.7...) > > I think I simply forgot to add the -c flag, silly me. Patch seems to > work, I'm getting some compile errors but I suppose it's a different > problem: > > avifile.DPJO1m.s:443:2: error: invalid operand for instruction > lretw > ^ > avifile.DPJO1m.s:580:2: error: invalid operand for instruction > lretw > ^ That's fixed in LLVM/Clang trunk. (I know, because I fixed it myself. A while ago, actually; I'm surprised Xcode doesn't have it yet.) Maybe the next version of Xcode will pick up the fix. Someone should really prod Apple about this :). > >> Do you actually not have the Wine vs. Mach cpu_type_t issue with Clang? I'd find that interesting. > > Yes, it doesn't appear with clang, and also not with gcc-mp-4.x from > macports. I suspect that's because Clang and newer GCC are smarter about identical typedefs. The ObjC BOOL vs. Wine BOOL issue wasn't about identical typedefs, because an ObjC BOOL is a "signed char" while a Wine BOOL is an "int". But a Mach cpu_type_t is an "integer_t"... which, ultimately, is a plain "int", the same as Wine's cpu_type_t. > I could open a radar myself (only have free membership), but > I don't mind it too much since the default gcc compiler doesn't work > anyway (wine bug 28030), so it might just as well get an error > compiling if we get clang working. Yeah, I'm not sure anyone really cares about the dead Apple GCC branch anymore... except AJ, but that's because his old Mac mini is stuck on 10.5, where we don't even have that problem. So long as Wine compiles with Apple GCC 4.x on Leopard, he'll be happy :). Chip > > Regards, > -- > Per Johansson

Jan. 2, 2013

Re: [PATCH] winebuild: Use Clang to assemble if its integrated assembler is being used.

by Per Johansson

On Wed, Jan 2, 2013 at 5:05 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > > Not sure if you can do it like that, as i understand it winebuild should always be able to crosscompile something, these ifdefs would destroy that feature. I suppose the correct way is to always use clang without target_alias prefix, but with the proper arch parameter. A combination of this patch and mine for llvm-mc. Either -arch or -Xassembler -triple -Xassembler target_alias Regards, -- Per Johansson

Jan. 2, 2013

Re: aclocal: Use -Werror when checking compiler flags.

by Alexandre Julliard

Per Johansson <per(a)morth.org> writes: > This makes clang exit with error on unsupported warnings. You'd need to check if -Werror is supported first. -- Alexandre Julliard julliard(a)winehq.org

Jan. 2, 2013