http://bugs.winehq.org/show_bug.cgi?id=32872
Bug #: 32872 Summary: Compilation broken if clang is installed, but not used for compilation. Product: Wine Version: 1.5.23 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools AssignedTo: wine-bugs@winehq.org ReportedBy: iive@yahoo.com Classification: Unclassified
When compiling I got the following error: -- make[1]: Entering directory `/dev/shm/fikus/wine-1.5.23/wine-1.5.23_GIT20130201_0618/dlls/avifile.dll16' ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared ./avifile.dll16.spec -m16 -Wb,--main-module,avifil32.dll -o avifile.dll16.so -lavifil32 ../../libs/port/libwine_port.a avifile.b0xGhP.s:443:2: error: invalid operand for instruction lretw ^ avifile.b0xGhP.s:580:2: error: invalid operand for instruction lretw ^ --
I did git-bisect between 1.5.22 and 1.5.23 and got: -- c14bdaf1ddb7d0e5587f63f1216b61c9ecb7a8c3 is the first bad commit commit c14bdaf1ddb7d0e5587f63f1216b61c9ecb7a8c3 Author: Charles Davis cdavis5x@gmail.com Date: Mon Jan 28 13:42:12 2013 -0700
winebuild: Use Clang to assemble if found.
:040000 040000 6d74670c5b85af40c0294786d2fe62b6cf69e950 ce57d3edff2b26c81e9d4e15be97beead7bbd5a9 M tools bisect run success --
Looking at the patch it is clear that if `clang` is found on the system it would be used unconditionally. Since I have an old version (LLVM-3.0), that I need for compiling the last stable Mesa3D v9.0 release (it is used for shaders).
The configure script doesn't check for clang support or version. There are no conditional option that would force gnu `as`, nor there is any code that would prefer `as` when `gcc` is used.
FYI. I'm on Slackware 14. GCC-4.7.2 (latest release atm). LLVM-3.0 fails. LLVM-3.2 seems to work fine.
I expect the bug to be fixed by checking for minimum clang version. If that is not feasible then there must be an configure option to select the toolchain and it should be documented in `configure -help`.
http://bugs.winehq.org/show_bug.cgi?id=32872
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |focht@gmx.net Ever Confirmed|0 |1
--- Comment #1 from Anastasius Focht focht@gmx.net 2013-02-01 15:06:09 CST --- Hello folks,
confirming.
Fedora 16 x86_64, clang 2.9
Regards
http://bugs.winehq.org/show_bug.cgi?id=32872
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=32872
tirili_@fastmail.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tirili_@fastmail.fm
http://bugs.winehq.org/show_bug.cgi?id=32872
Ryan Schmidt wine-2013@ryandesign.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine-2013@ryandesign.com
--- Comment #2 from Ryan Schmidt wine-2013@ryandesign.com 2013-02-04 18:21:39 CST --- MacPorts users are experiencing this issue as well, with clang versions earlier than Apple clang-425.0.24 which is included in Xcode 4.6.
https://trac.macports.org/ticket/37905
Because wine never built correctly with clang before, in MacPorts we are setting the CC and CXX environment variables to a non-clang compiler so we are surprised that this is not being honored anymore.
http://bugs.winehq.org/show_bug.cgi?id=32872
Morgan Stair winehq@tadmuck.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@tadmuck.com
http://bugs.winehq.org/show_bug.cgi?id=32872
--- Comment #3 from Morgan Stair winehq@tadmuck.com 2013-02-05 10:36:04 CST --- Confirming that Ryan's solution in comment 2 works for MacPorts users. The MacPorts build was failing for me. I upgraded to Xcode 4.6 (the latest version). Now it builds.
http://bugs.winehq.org/show_bug.cgi?id=32872
Eric Gallager egall@gwmail.gwu.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |egall@gwmail.gwu.edu
--- Comment #4 from Eric Gallager egall@gwmail.gwu.edu 2013-02-06 22:22:19 CST --- As a follow-up to the MacPorts situation, the project has started using the following patchset as a workaround: https://trac.macports.org/changeset/102696
http://bugs.winehq.org/show_bug.cgi?id=32872
--- Comment #5 from Austin English austinenglish@gmail.com 2013-02-11 19:11:22 CST --- On linux, with clang installed locally, I get some warnings now: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/../../../../x86_64-pc-linux-gnu/bin/ld: advapi32.dll-auboib.spec.o: warning: relocation in readonly section `.eh_frame'. /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in a shared object.
when gcc is used to compile, but clang's assembler is used.
It's non-fatal, but annoying. I'm not sure who's bug this would be though, if anyone's..
http://bugs.winehq.org/show_bug.cgi?id=32872
--- Comment #6 from Henri Verbeet hverbeet@gmail.com 2013-02-15 22:18:56 CST --- For what it's worth, I don't think it really makes sense to prefer Clang if it's installed just because OS X comes with a questionable build environment by default. (And for what it's worth, you can install e.g. proper gcc 4.7 even on OS X, either through something like Fink or MacPorts, or by just building it yourself.) I imagine the proper way to fix this is for winebuild to just respect the CCAS and CCASFLAGS environment variables (and similarly LD, LDFLAGS, etc.) when present, unless overridden by command line options, and just fallback to the system default otherwise. Or perhaps make configure pass appropriate command line options, if we don't want to look at the environment in winebuild.
http://bugs.winehq.org/show_bug.cgi?id=32872
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl 2013-02-16 00:14:07 CST --- @comment 5: For more reference material: https://bugs.gentoo.org/show_bug.cgi?id=455308
This does look like a problem with clang, but there's also a chance winegcc does something odd.
http://bugs.winehq.org/show_bug.cgi?id=32872
Vince vyankey@bresnan.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vyankey@bresnan.net
http://bugs.winehq.org/show_bug.cgi?id=32872
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
http://bugs.winehq.org/show_bug.cgi?id=32872
--- Comment #8 from Austin English austinenglish@gmail.com 2013-06-03 17:11:00 CDT --- There's a similar problem. On linux64, with wine32 and clang installed, running winemaker fails unless --wine32 is specified. By default, it will attempt to use clang to assemble, and it will do so as a 64-bit build:
austin@aw25 ~/b $ winegcc -v -mwindows -mno-cygwin -o b.exe test_freopen.o -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid winebuild -v -fno-asynchronous-unwind-tables -D_REENTRANT -fPIC --exe -o b.exe-IGE76X.spec.o -F b.exe --subsystem windows -L/usr/local/lib/wine -L/usr/local/lib -- test_freopen.o /usr/local/lib/wine/libodbc32.def /usr/local/lib/wine/libole32.def /usr/local/lib/wine/liboleaut32.def /usr/local/lib/wine/libwinspool.def /usr/local/lib/wine/libodbccp32.def /usr/local/lib/wine/libuuid.a /usr/local/lib/wine/libmsvcrt.def /usr/local/lib/wine/libshell32.def /usr/local/lib/wine/libcomdlg32.def /usr/local/lib/wine/libgdi32.def /usr/local/lib/wine/libadvapi32.def /usr/local/lib/wine/libuser32.def /usr/local/lib/wine/libwinecrt0.a /usr/local/lib/wine/libkernel32.def /usr/local/lib/wine/libntdll.def /usr/local/bin/clang -xassembler -c -o b.nV3xVG.o b.AI1XuP.s /usr/bin/ld -r -o b.0IxHKw.o b.nV3xVG.o test_freopen.o /usr/local/lib/wine/libuuid.a /usr/local/lib/wine/libwinecrt0.a /usr/bin/ld: Relocatable linking with relocations from format elf32-i386 (test_freopen.o) to format elf64-x86-64 (b.0IxHKw.o) is not supported winebuild: /usr/bin/ld failed with status 1 winegcc: winebuild failed
using 'winemaker --wine32' instead is a workaround.
http://bugs.winehq.org/show_bug.cgi?id=32872
Alan A. grsfdhj@tiscali.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grsfdhj@tiscali.it
--- Comment #9 from Alan A. grsfdhj@tiscali.it 2013-06-08 04:45:58 CDT --- The issue reported in the first comment is still happening as-is in wine-1.6-rc1.
http://bugs.winehq.org/show_bug.cgi?id=32872
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |3987913453fc8c723068997f8af | |7c6a66f72f0c0 Status|NEW |RESOLVED Resolution| |FIXED Regression SHA1| |c14bdaf1ddb7d0e5587f63f1216 | |b61c9ecb7a8c3
--- Comment #10 from André H. nerv@dawncrow.de 2013-06-10 15:18:24 CDT --- should be fixed by http://source.winehq.org/git/wine.git/commitdiff/3987913453fc8c723068997f8af... and previous commits
http://bugs.winehq.org/show_bug.cgi?id=32872
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2013-06-14 13:24:58 CDT --- Closing bugs fixed in 1.6-rc2.