http://bugs.winehq.org/show_bug.cgi?id=20306
Summary: Wine does not compile with LLVM Product: Wine Version: 1.1.31 Platform: Macintosh OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P3 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: piotr@layer22.com
Created an attachment (id=24006) --> (http://bugs.winehq.org/attachment.cgi?id=24006) Wine compile log
Wine fails to find symbols when compiled with LLVM under Mac OS X Snow Leopard 10.6.1
Wine 1.1.30 did not compile either.
llvm-gcc-4.2 -m32 -dynamiclib -install_name /usr/local/Cellar/wine/1.1.31/lib/libwine.1.dylib -compatibility_version 1 -current_version 1.0 c_037.o c_10000.o c_10006.o c_10007.o c_10029.o c_1006.o c_10079.o c_10081.o c_1026.o c_1250.o c_1251.o c_1252.o c_1253.o c_1254.o c_1255.o c_1256.o c_1257.o c_1258.o c_1361.o c_20127.o c_20866.o c_20932.o c_21866.o c_28591.o c_28592.o c_28593.o c_28594.o c_28595.o c_28596.o c_28597.o c_28598.o c_28599.o c_28600.o c_28603.o c_28604.o c_28605.o c_28606.o c_424.o c_437.o c_500.o c_737.o c_775.o c_850.o c_852.o c_855.o c_856.o c_857.o c_860.o c_861.o c_862.o c_863.o c_864.o c_865.o c_866.o c_869.o c_874.o c_875.o c_878.o c_932.o c_936.o c_949.o c_950.o casemap.o collation.o compose.o config.o cptable.o debug.o fold.o ldt.o loader.o mbtowc.o mmap.o port.o sortkey.o string.o utf8.o wctomb.o wctype.o version.o ../../libs/port/libwine_port.a -L/usr/X11R6/lib -arch i386 -m32 -framework CoreServices -lz -lGL -lGLU -lGL -lGLU -o libwine.1.0.dylib Undefined symbols: "_wine_set_fs", referenced from: llvm bitcode in ldt.o "_interlocked_xchg_add", referenced from: llvm bitcode in debug.o "_wine_call_on_stack", referenced from: llvm bitcode in port.o "_wine_get_fs", referenced from: llvm bitcode in ldt.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [libwine.1.0.dylib] Error 1 make[1]: *** [wine] Error 2 make: *** [libs] Error 2 Exit code: 512
http://bugs.winehq.org/show_bug.cgi?id=20306
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Platform|Macintosh |Other Resolution| |INVALID
--- Comment #1 from Jeff Zaroyko jeffz@jeffz.name 2009-10-10 07:08:27 --- So file a bug with the llvm project.
http://bugs.winehq.org/show_bug.cgi?id=20306
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #2 from Jeff Zaroyko jeffz@jeffz.name 2009-10-10 07:08:44 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #3 from Austin English austinenglish@gmail.com 2009-10-10 13:37:37 --- (In reply to comment #1)
So file a bug with the llvm project.
It very well may need fixing on both sides (wine and llvm's)...
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #4 from Jeff Zaroyko jeffz@jeffz.name 2009-10-10 17:50:06 --- (In reply to comment #3)
(In reply to comment #1)
So file a bug with the llvm project.
It very well may need fixing on both sides (wine and llvm's)...
If llvm is supposed to be a replacement/alternative to gcc it should just work.
http://bugs.winehq.org/show_bug.cgi?id=20306
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID |
--- Comment #5 from Austin English austinenglish@gmail.com 2009-10-11 01:32:14 --- (In reply to comment #4)
(In reply to comment #3)
(In reply to comment #1)
So file a bug with the llvm project.
It very well may need fixing on both sides (wine and llvm's)...
If llvm is supposed to be a replacement/alternative to gcc it should just work.
I don't see where that's claimed, and I still think this is a valid bug. Reopening.
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #6 from Jeff Zaroyko jeffz@jeffz.name 2009-10-11 02:01:21 --- (In reply to comment #5)
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #1)
So file a bug with the llvm project.
It very well may need fixing on both sides (wine and llvm's)...
If llvm is supposed to be a replacement/alternative to gcc it should just work.
I don't see where that's claimed, and I still think this is a valid bug. Reopening.
http://llvm.org/releases/download.html "This is most useful if you want a no-fuss drop-in replacement for Apple GCC"
http://llvm.org/devmtg/2008-08/Naroff_Clang.pdf "Drop in replacement for GCC 4.2"
http://llvm.org/cmds/llvm-ld.html "The llvm-ld tools attempts to mimic the interface provided by the default system linker so that it can act as a drop-in replacement."
http://bugs.winehq.org/show_bug.cgi?id=20306
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #7 from Austin English austinenglish@gmail.com 2009-10-11 04:02:52 --- (In reply to comment #6)
http://llvm.org/cmds/llvm-ld.html "The llvm-ld tools attempts to mimic the interface provided by the default system linker so that it can act as a drop-in replacement."
'Attempts to', not 'is'. Regardless, wine is pretty portable, and strives to be so. Porting to lllvm seems reasonable. Confirming.
http://bugs.winehq.org/show_bug.cgi?id=20306
Yann Droneaud yann@droneaud.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yann@droneaud.fr
--- Comment #8 from Yann Droneaud yann@droneaud.fr 2009-10-26 06:53:26 --- When using the even more experimental clang C frontend (from llvm 2.6), errors are related to extern inline
- when some asm() create a symbols already defined as a extern inline, the assembler found two definitions;
- when object files are linked together, ld report those extern inline symbols as multiple defined.
IMHO, wine should not rely on "extern inline" asis since it seems to be GCC specific behavor which is reported incompatible with C99. See http://gcc.gnu.org/ml/gcc/2006-11/msg00006.html http://www.greenend.org.uk/rjk/2003/03/inline.html
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #9 from Alexandre Julliard julliard@winehq.org 2009-10-26 07:54:22 --- (In reply to comment #8)
When using the even more experimental clang C frontend (from llvm 2.6), errors are related to extern inline
- when some asm() create a symbols already defined as a extern inline, the
assembler found two definitions;
- when object files are linked together, ld report those extern inline symbols
as multiple defined.
IMHO, wine should not rely on "extern inline" asis since it seems to be GCC specific behavor which is reported incompatible with C99. See http://gcc.gnu.org/ml/gcc/2006-11/msg00006.html http://www.greenend.org.uk/rjk/2003/03/inline.html
All the extern inline asm functions should be inside a #ifdef __GNUC__, if some aren't they should be fixed. But if llvm defines __GNUC__ then it better be compatible.
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #10 from Yann Droneaud yann@droneaud.fr 2009-10-26 08:36:27 --- (In reply to comment #8)
When using the even more experimental clang C frontend (from llvm 2.6), errors are related to extern inline
- when some asm() create a symbols already defined as a extern inline, the
assembler found two definitions;
- when object files are linked together, ld report those extern inline symbols
as multiple defined.
IMHO, wine should not rely on "extern inline" asis since it seems to be GCC specific behavor which is reported incompatible with C99. See http://gcc.gnu.org/ml/gcc/2006-11/msg00006.html http://www.greenend.org.uk/rjk/2003/03/inline.html
I'm having the same problem regarding asm construct conflicting with extern inline symbols when building with CFLAGS="--std=c99".
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2009-10-26 09:06:55 --- (In reply to comment #10)
I'm having the same problem regarding asm construct conflicting with extern inline symbols when building with CFLAGS="--std=c99".
Please file a separate bug for that, and attach a log of the errors you get.
http://bugs.winehq.org/show_bug.cgi?id=20306
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20306
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #12 from Luca Bennati lucak3@gmail.com 2010-09-04 11:39:57 CDT --- llvm+clang 2.7 and wine-1.3.2, compiled with CC=clang CXX=clang CFLAGS="-std=gnu89 -O0" ./configure --prefix=/usr --sysconfdir=/etc --with-x --without-capi --without-gsm --without-icns Not a single error!
http://bugs.winehq.org/show_bug.cgi?id=20306
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #13 from Dan Kegel dank@kegel.com 2010-09-04 12:43:41 CDT --- So, now that we build with -std=gnu89, can this bug can be closed? Or should we first adjust configure.ac to add that option if we notice llvm being used?
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #14 from Austin English austinenglish@gmail.com 2010-09-04 13:55:08 CDT --- (In reply to comment #13)
So, now that we build with -std=gnu89, can this bug can be closed?
I don't see where that change took place at?
Or should we first adjust configure.ac to add that option if we notice llvm being used?
Wine compiles fine now with simply: $ export CC=clang $ ./configure
however, it crashes on run for me (with -O2). I'll attach a backtrace.
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #15 from Austin English austinenglish@gmail.com 2010-09-04 13:55:25 CDT --- Created an attachment (id=30558) --> (http://bugs.winehq.org/attachment.cgi?id=30558) backtrace from running wine notepad
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #16 from Dan Kegel dank@kegel.com 2010-09-04 13:56:57 CDT --- Compiling and running are two different things, I think. Sounds like this bug can be closed, and someone should open a new one for crashes in wine built with llvm.
http://bugs.winehq.org/show_bug.cgi?id=20306
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #17 from Austin English austinenglish@gmail.com 2010-09-04 14:07:19 CDT --- (In reply to comment #16)
Compiling and running are two different things, I think. Sounds like this bug can be closed, and someone should open a new one for crashes in wine built with llvm.
Yeah, true.
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #18 from Austin English austinenglish@gmail.com 2010-09-04 16:45:04 CDT --- (In reply to comment #17)
(In reply to comment #16)
Compiling and running are two different things, I think. Sounds like this bug can be closed, and someone should open a new one for crashes in wine built with llvm.
Yeah, true.
Actually, works fine if you do: CC=clang CXX=clang CFLAGS="-std=gnu89 -g" ./configure
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #19 from Dmitry Timoshkov dmitry@codeweavers.com 2010-09-05 00:39:46 CDT --- Is there a fix in Wine that made this bug disappear, or LLVM was fixed instead? In the latter case this bug should be closed as invalid.
http://bugs.winehq.org/show_bug.cgi?id=20306
--- Comment #20 from Austin English austinenglish@gmail.com 2010-09-05 00:41:45 CDT --- (In reply to comment #19)
Is there a fix in Wine that made this bug disappear, or LLVM was fixed instead? In the latter case this bug should be closed as invalid.
I think a combination of both. There are quite a few patches in wine for Clang fixes (some warnings, some errors).
http://bugs.winehq.org/show_bug.cgi?id=20306
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org 2010-09-18 13:05:56 CDT --- Closing bugs fixed in 1.3.3.