http://bugs.winehq.org/show_bug.cgi?id=17340
Summary: winebuild does not respect --host & --target configure parameters Product: Wine Version: unspecified Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools AssignedTo: wine-bugs@winehq.org ReportedBy: cruiseoveride@gmail.com
As the title suggests, winebuild does not use the compiler triplet specified at configure time.
I noticed this problem when building on 64bit Fedora.
I keep a handy dandy toolchain (i386-linux-xxxxx) for building 32bit apps.
But winebuild refuses to use it (but the rest of the gnu make build is fine)
winebuild could be modified by autoconf/automake to reflect the proper default toolchain.
eg. in tools/winebuild/main.c 86 char *as_command = NULL; 87 char *ld_command = NULL;
The NULLs can be changed to @LD@ and @AS@ and taken from autoconf
Thank you.
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2009-02-11 04:24:11 --- winebuild has a --target option for that purpose. Please show the exact error you get.
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #2 from cruiseoveride cruiseoveride@gmail.com 2009-02-11 09:55:28 --- (In reply to comment #1)
winebuild has a --target option for that purpose. Please show the exact error you get.
Thats correct. However the Makefile does not pass --target to winebuild/winegcc, and thus making it completely useless.
For example, while building acledit
** Here the correct toolchain is used i386-linux-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o main.o main.c
** And here winegcc/winebuild is trying to call the system wide /usr/bin/ld ** Which in turn results in cross arch issues ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./acledit.spec main.o -o acledit.dll.so -lkernel32 ../../libs/port/libwine_port.a /usr/bin/ld: Relocatable linking with relocations from format elf32-i386 (main.o) to format elf64-x86-64 (acledit.SEum4r.o) is not supported winebuild: /usr/bin/ld -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed make: *** [acledit.dll.so] Error 2
And obviously after editing the mentioned lines in winebuild, the build correctly uses i386-linux-ld/as
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2009-02-11 10:05:52 --- (In reply to comment #2)
Thats correct. However the Makefile does not pass --target to winebuild/winegcc, and thus making it completely useless.
It does in current git.
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #4 from cruiseoveride cruiseoveride@gmail.com 2009-02-11 10:19:56 --- The last commit i have in my git is 8ab829a68a993434506d5307e7681fc97bbc3fee
I'm doing a distclean and config/make again. Unless there were changes done overnight, it should yield the same result.
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #5 from cruiseoveride cruiseoveride@gmail.com 2009-02-11 10:20:43 --- And yes, Exact sane error
[...] make[2]: Entering directory `/home/vikky/Programs/wine-git/dlls/acledit' i386-linux-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o main.o main.c ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./acledit.spec main.o -o acledit.dll.so -lkernel32 ../../libs/port/libwine_port.a /usr/bin/ld: Relocatable linking with relocations from format elf32-i386 (main.o) to format elf64-x86-64 (acledit.I1fMcx.o) is not supported winebuild: /usr/bin/ld -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed make[2]: *** [acledit.dll.so] Error 2 make[2]: Leaving directory `/home/vikky/Programs/wine-git/dlls/acledit' make[1]: *** [acledit] Error 2 make[1]: Leaving directory `/home/vikky/Programs/wine-git/dlls' make: *** [dlls] Error 2
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2009-02-11 10:29:20 --- How did you run configure? Could you please attach your config.log?
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #7 from cruiseoveride cruiseoveride@gmail.com 2009-02-11 11:03:01 --- Created an attachment (id=19383) --> (http://bugs.winehq.org/attachment.cgi?id=19383) config log
Only --host should be necessary, but this didn't seem to work well so i provided --build too
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2009-02-11 11:05:33 --- This is wrong, you shouldn't pass --build if you want to cross-compile. If build and host are the same configure decides you are not cross-compiling.
http://bugs.winehq.org/show_bug.cgi?id=17340
cruiseoveride cruiseoveride@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #19383|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #9 from cruiseoveride cruiseoveride@gmail.com 2009-02-11 11:12:39 --- (In reply to comment #8)
This is wrong, you shouldn't pass --build if you want to cross-compile. If build and host are the same configure decides you are not cross-compiling.
How is it supposed to be done?
[12:11:41 ~/Programs/wine-git] <> ./configure --prefix=/opt/wine --libdir=/opt/wine/lib --host=i386-linux configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking build system type... x86_64-unknown-linux-gnu checking host system type... i386-pc-linux-gnu checking whether make sets $(MAKE)... yes checking for i386-linux-gcc... i386-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no [...]
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2009-02-11 12:26:04 --- (In reply to comment #9)
(In reply to comment #8)
This is wrong, you shouldn't pass --build if you want to cross-compile. If build and host are the same configure decides you are not cross-compiling.
How is it supposed to be done?
It's not really supposed to be done, cross-compiling is meant for building PE binaries. So we'd have to hack configure to make it detect a cross compile even if the resulting binary can run natively.
Why do you need a cross compile actually? Why doesn't a normal build work for you?
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2009-02-11 12:35:51 --- Created an attachment (id=19386) --> (http://bugs.winehq.org/attachment.cgi?id=19386) Set host alias even if not cross-compiling.
You could try something like this.
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #12 from cruiseoveride cruiseoveride@gmail.com 2009-02-11 14:23:27 --- (In reply to comment #11)
Created an attachment (id=19386)
--> (http://bugs.winehq.org/attachment.cgi?id=19386) [details]
Set host alias even if not cross-compiling.
You could try something like this.
That has a strange result.. ../../tools/winegcc/winegcc -b i386-linux -B../../tools/winebuild -shared ./acledit.spec main.o -o acledit.dll.so -lkernel32 ../../libs/port/libwine_port.a winegcc: i386-linux-i386-linux-gcc failed
http://bugs.winehq.org/show_bug.cgi?id=17340
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2009-02-12 11:30:13 --- (In reply to comment #12)
That has a strange result.. ../../tools/winegcc/winegcc -b i386-linux -B../../tools/winebuild -shared ./acledit.spec main.o -o acledit.dll.so -lkernel32 ../../libs/port/libwine_port.a winegcc: i386-linux-i386-linux-gcc failed
Yes that one is a bug, it should be fixed in git.
http://bugs.winehq.org/show_bug.cgi?id=17340
cruiseoveride cruiseoveride@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #14 from cruiseoveride cruiseoveride@gmail.com 2009-02-12 13:27:10 --- Everything works properly in the current git.
http://bugs.winehq.org/show_bug.cgi?id=17340
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2009-02-13 11:11:35 --- Closing bugs fixed in 1.1.15.
http://bugs.winehq.org/show_bug.cgi?id=17340
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |htl10@users.sourceforge.net
--- Comment #16 from Hin-Tak Leung htl10@users.sourceforge.net 2009-02-16 17:43:59 --- Alexandre made a commit (4d135d9a71477baa9ffca530b2e3046c3e0a7a26) to undo some of the damage from the "fix" in 1.1.15. Nevertheless, I like to point out to the original poster that there is no need to keep a cross-compile toolchain (i386-linux-xxxxx) for building 32bit apps on 64-bit fedora. (I use x86_64 fedora myself). Just passing -m32 to both the compiler (CFLAGS for c, CXXFLAGS for c++ , FGLAGS for fortran) and the linker (LDFLAGS) would do.
That has been the case for all multi-arch OSes since multi-arch CPU support was available in the compiler. i.e. since x86_64 and ppc64 CPUs were available. I do that quite regularly for wine, R, ghostscript, and occasionally something else. There are distinct advantages e.g. for memory footprint, and the 32-bit build tends to better tested and have fewer bugs, etc.
FWIW, on multi-arch (x86_64/x86) Solaris and (ppc/ppc64) Mac OS X, the default behavior of the GCC suite is to generate 32-bit code, so the opposite - "-m64" is needed if one wants to build 64-bit apps on Solaris and Mac OS X.
http://bugs.winehq.org/show_bug.cgi?id=17340
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org Status|CLOSED |UNCONFIRMED Resolution|FIXED |
--- Comment #17 from Scott Ritchie scott@open-vote.org 2009-02-17 03:02:05 --- The mailing list points to the change in this bug as responsible for the new build failures many of us are experiencing - I still haven't been able to get 1.1.15 built in a package yet.
http://bugs.winehq.org/show_bug.cgi?id=17340
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #18 from Alexandre Julliard julliard@winehq.org 2009-02-17 03:40:21 --- This bug is fixed, please don't reopen it. If the fix causes some other problems please file a new bug.
http://bugs.winehq.org/show_bug.cgi?id=17340
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2009-02-17 03:40:34 --- Closing again.
http://bugs.winehq.org/show_bug.cgi?id=17340
--- Comment #20 from Hin-Tak Leung htl10@users.sourceforge.net 2009-02-18 12:43:09 --- (In reply to comment #17)
The mailing list points to the change in this bug as responsible for the new build failures many of us are experiencing - I still haven't been able to get 1.1.15 built in a package yet.
You didn't read my comment 16. I already mentioned that Alexandre made further changes in git to undo the damage, so likely it will "work as usual" in 1.1.16. If you can't wait for 1.1.16 or build from git, you can pretend to be cross-compiling by creating three symbolic links x86_64-redhat-linux-{as,ld,nm} pointing to {as,ld,nm}. (or x86_64-unknown-linux-gnu-{} to {}, depending on what $build/$host dkg is trying to set).
-
wine-bugs＠winehq.org