There seems to be some multilib related issue at work here, switching from eselect-compiler back to a non-masked gcc-config allows me to at least pass the failure point. (Tested with wine 0.9.9, 0.9.10 and 0.9.11) Will post build logs for both eselect-compiler and gcc-config-1* in a moment.
Created attachment 83889 [details] Log of build failure (eselect-compiler)
Created attachment 83890 [details] Start of build log with gcc-config
This is because the wine ebuild is using x86_64-pc-linux-gnu-gcc instead of i686-pc-linux-gnu-gcc to compile...
Wine sets ABI=x86 in pkg_setup(), and then passes CC=$(tc-getCC) to econf. Shouldn't this take care of it? Though according to the cli output when using an older gcc-config, wine still builds using x86_64-pc-linux-gnu-gcc. Sorry if I'm on the completely wrong track here, I'm not familiar with how the toolchain is handled.
Created attachment 83938 [details, diff] wine-0.9.10.ebuild.patch Please try with this patch.
Created attachment 83939 [details, diff] wine-0.9.10.ebuild.patch Actually, this one's a bit cleaner...
With the attached patch wine passes the point it failed at before, but fails further along. i686-pc-linux-gnu-gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -march=athlon64 -O2 -pipe -g -ggdb -o winstation.o winstation.c ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./glu32.spec glu.o -o glu32.dll.so -L../../dlls -L../../dlls/kernel32 -L../../dlls/ntdll -lkernel32 -lntdll -L../../libs/wine -lwine -L/usr/lib64 -lSM -lICE -lXxf86dga -lXxf86vm -lXext -lX11 -lGL -lGLU -L../../libs/port -lwine_port -Wl,-O1 -Wl,-Bdirect -Wl,--as-needed ld: Relocatable linking with relocations from format elf32-i386 (glu.o) to format elf64-x86-64 (glu32.2FpC5f.o) is not supported winebuild: ld -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed.
i'm not adding anything to wine beyond one multilib call and setting ABI to x86
*** Bug 136177 has been marked as a duplicate of this bug. ***
*** Bug 136253 has been marked as a duplicate of this bug. ***
wine-0.9.15 now compiles on amd64 with eselect-compiler.
did you not read my last comment ? simplify the multilib code instead of duplicating the same crap over and over ine builds
WTF are you talking about? Did you actually look in cvs? I didn't use what I attached here. It's fixed. It's 4 lines. We need to set CHOST, CBUILD, LD, and AS. We should only need to set CHOST and CBUILD, but there are no i686-* binutils installed thus we need to override LD and AS to pass the appropriate command line arguments. Alternatively, the configure script has logic to work on CHOST=x86_64-* if we pass --enable-win64, but I don't know what other effects that has, and I see you commented that out, so I didn't go that route.
i did look in cvs (i reverted your changes after all) and i'm telling you that isnt acceptable dont get into a commit war over this as the maintainer will win there's no reason those fun details cannot be offloaded to an eclass / eselect-compiler ... there is nothing wine-specific about them
*** Bug 136365 has been marked as a duplicate of this bug. ***
Works on my system after sync'ing.
Then if you saw my commit, you saw my comment in there about LD and AS. As you're aware, ld and as are handled by binutils-config, not eselect-compiler. I have plans to provide wrappers for binutils in the same way they are being provided for the compiler, and that will allow us to compile multilib packages by just setting CHOST. I don't see why you have such an objection to a 4 variables being set. Yes, it'd be nice to just set 1 (CHOST), but we have to override CBUILD as well since it was set by portage, and we have to override LD and AS for the reasons stated above. This is just how it needs to be handled for now as we migrate away from $ABI hacks in the toolchain and get everything working with $CHOST- prefixes. If you don't like having those lines in the ebuild, then feel free to use either of your other two options: 1. remove amd64 from KEYWORDS 2. test out --enable-win64
all irrelevant there's no reason whatsoever you cant move that logic to the multilib eclass and have ebuilds call that function thus as we move on to bigger and better things, we dont have to constantly maintain hacks scattered throughout ebuilds in the tree, we just update the *one* function in the shared eclass
Additionally, you don't need to set CC=... or ABI=... . I took out the ABI=, but left in the CC= because I was under the impression it was needed for something else, but ChangeLog indicates it's just for amd64, so it's really just adding 2 additional variables being set for now.
Well, I'm not going to add something to an eclass which is only used/needed by one ebuild.
incorrect, wine isnt the only package that is compiled from-source on an amd64 host to produce x86 binaries
Well, it's the only one that needs to set LD and AS. All the others don't use binutils directly, so they work right just by using i686-pc-linux-gnu-gcc. I'm not going to garble up an eclass with even more hacks to do what should be handled by the toolchain.
there's your answer then, eselect-compiler sucks
Created attachment 88969 [details, diff] wine-0.9.15.ebuild.patch The patch to 0.9.15 for anyone who actually wants wine on amd64. And eselect-compiler is doing what it's supposed to here. There's just no analagous wrapper for binutils at present. This is something that's been talked about in the past. I thought you of all people would be happy to ditch the whole ABI crap.
(In reply to comment #24) > Created an attachment (id=88969) [edit] > wine-0.9.15.ebuild.patch > > The patch to 0.9.15 for anyone who actually wants wine on amd64. This puts all libraries (*.dll.so etc.) in /usr/lib64/wine instead of /usr/lib32/wine
*** Bug 136577 has been marked as a duplicate of this bug. ***
can you guys please work out some sort of consensus? the current situation just isn't acceptable for users as the numerous dupes show thanks...
Well for those users that can't find any better solution in order to emerge wine on amd64, a little quote from gentoo-amd64 list, as Jan Jitse Venselaar wrote: > emerge --unmerge eselect-compiler > emerge "<gcc-config-1.99" --oneshot > emerge --nodeps --oneshot wine While the developer involved reach a consensus this can help someone as it helped me.
*** Bug 136725 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > Created an attachment (id=88969) [edit] > wine-0.9.15.ebuild.patch Don't use that patch.. It's never correct to assume a CHOST=
It is in this case, solar... or would you prefer users be forced to do "CHOST='i686-pc-linux-gnu' emerge wine". Quite honestly, I'd be fine with that in which case unkeyword wine.
(In reply to comment #31) > It is in this case, solar... or would you prefer users be forced to do > "CHOST='i686-pc-linux-gnu' emerge wine". Quite honestly, I'd be fine with that > in which case unkeyword wine. To be honest I think you should p.mask gcc-config-2.x pending approval from the gcc-config-1.x author you did not have his permission or blessing to hijack the package.
there's no reason this cant be handled in an eclass dropping ABI/CC from the ebuild and adding just eselect stuff implies wine requires eselect-compiler and no upgrade path is offered -> unacceptable
(In reply to comment #24) > And eselect-compiler is doing what it's supposed to here. There's just no > analagous wrapper for binutils at present. Tell me how come, if eselect-compiler is working as it should coupled with the fact that there is no binutils wrapper at all: 1) eselect-compiler decides not to replicate the functionality of gcc-config by allowing the use of the i686 and not the x86_64 gcc compiler to work on wine (see your own comment #3). 2) if I mask eselect-compiler and emerge an edit of the wine ebuild, which does not have eselect-compiler as a dependency, wine compiles fine. This implies to me that eselect-compiler is NOT working properly and we don't NEED a simmilar binutils wrapper. Please enligten me as to why you insist that your solution is the ONLY solution, which it clearly is not, as has been shown in this thread (comment #28) and in the forums. As a last note I find that, in my opinion, having eselect-compiler as a dependency for wine and other packages is idiotic and against the spirit of gentoo.
hrm, hadnt noticed the eselect-compiler in DEPEND, ive cut that from cvs too
> To be honest I think you should p.mask gcc-config-2.x pending approval from the > gcc-config-1.x author you did not have his permission or blessing to hijack the > package. > Uhm, solar. I responded to this on -dev and you seem to have missed it. I _WAS_ maintaining gcc-config-1.x for multilib purposes, and last year we (toolchain@ and amd64@) discussed the limitations, and came up with plans to fix them. That is what resulted in eselect-compiler.
(In reply to comment #33) > there's no reason this cant be handled in an eclass > > dropping ABI/CC from the ebuild and adding just eselect stuff implies wine > requires eselect-compiler and no upgrade path is offered -> unacceptable > It doesn't require eselect-compiler. It's just cleaner than hacking away with ABI stuff. vapier, would you prefer something like this set in profiles: ASFLAGS_x86="--32" and have tc_getAS do ugly hack crap to append the --32 if there is no $CHOST-as available? I think that is ugly and what we want to avoid. I don't see what you want out of a eclass for this purpose.
(In reply to comment #34) > (In reply to comment #24) > > > And eselect-compiler is doing what it's supposed to here. There's just no > > analagous wrapper for binutils at present. > > Tell me how come, if eselect-compiler is working as it should coupled with the > fact that there is no binutils wrapper at all: > > 1) eselect-compiler decides not to replicate the functionality of gcc-config by > allowing the use of the i686 and not the x86_64 gcc compiler to work on wine > (see your own comment #3). I'm sorry I don't understand what you are asking here. The main issue is that we want to stop using ABI where possible and just base things off of CHOST. > 2) if I mask eselect-compiler and emerge an edit of the wine ebuild, which does > not have eselect-compiler as a dependency, wine compiles fine. > > This implies to me that eselect-compiler is NOT working properly and we don't > NEED a simmilar binutils wrapper. Please enligten me as to why you insist that > your solution is the ONLY solution, which it clearly is not, as has been shown > in this thread (comment #28) and in the forums. We NEED a similar binutils wrapper to avoid the hacks that are in place here and let everything be based off of CHOST. Right now, the only thing the ABI=x86 is doing for us is adding -L/emul/... CC, LD, and AS are being set by the configure script properly when CHOST=x86_64-*. > As a last note I find that, in my opinion, having eselect-compiler as a > dependency for wine and other packages is idiotic and against the spirit of > gentoo. It is not a dependency of packages any more than gcc-config is a dependency. I placed it there because it makes it easier to compile packages for non-standard CHOSTs and spanky didn't want more cruft than was neccessary. As it is, I'm not going to clog up toolchain-funcs.eclass with ugly hacks to support the AS and LD that need to be set here. The fact is the configure script already sets the CFLAGS, ASFLAGS, and LDFLAGS to compile for 32bit when it sees CHOST=x86_64-*. The problem is that it doesn't look in /emul/... when linking. So we have 2 options: 1) Leave CHOST=x86_64 and tell wine to look in /emul/... when linking 2) Set CHOST=i686-* which results in it looking there automatically, but means we neet to also set LD and AS since the configure script doesn't. Option 1 will work for both old and new gcc-config, and we won't need to set ABI=... in the ebuild. Option 2 would require some logic to only do it for eselect-compiler.
your solution required eselect-compiler as you dropped support for anything else toolchain-funcs.eclass is not for multilib, that is what multilib.eclass is for wine doesnt search /emul/... because that's a Gentoo hack for storing 32bit libs, it doesnt belong in ebuilds it doesnt really matter to me how you implement these hacks as long as it isnt in the wine ebuild
*** Bug 137106 has been marked as a duplicate of this bug. ***
cat compile on amd64 wine-0.9.15 whith ebuild This is failt: ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib CC=x86_64-pc-linux-gnu-gcc --sysconfdir=/etc/wine --with-curses --with-opengl --with-x --disable-trace --disable-debug --libdir=/usr/lib32 --build=x86_64-pc-linux-gnu so compile ok: ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/wine --with-curses --with-opengl --with-x --disable-trace --disable-debug --libdir=/usr/lib32 bau say: *** Warning: FreeType is missing. *** Fonts will not be built. Dialog text may be invisible or unaligned.
(In reply to comment #39) > your solution required eselect-compiler as you dropped support for anything > else right, because gcc-config-1.x uses the ABI hack which is ugly and being phased out. would you prefer a block againse that? I'm fine with that, too. > toolchain-funcs.eclass is not for multilib, that is what multilib.eclass is for exactly, but the problem is in setting a correct LD and AS which _IS_ toolchain related. I don't think it belongs in there either which was my point. The problem is that we don't have the proper $CHOST-{as,ld} available on amd64. > wine doesnt search /emul/... because that's a Gentoo hack for storing 32bit > libs, it doesnt belong in ebuilds Right, but it NEEDS to search that somehow by some hack because you want wine keyworded for amd64 before the toolchain/portage is really ready for this properly. > it doesnt really matter to me how you implement these hacks as long as it isnt > in the wine ebuild Well guess what, it has to be implemented somewhere. If you don't want it in the wine ebuild, then by all means add /emul/... to the default search path in binutils, but I personally don't like that idea. I'd rather just see this in wine's ebuild since you're the only package actually doing this. And besides the hacks are already there to get it to work on amd64, the're just becoming less of a hack (ABI) and becoming more correct usage (setting CHOST/LD/AS). (In reply to comment #41) > cat compile on amd64 wine-0.9.15 whith ebuild > This is failt: > ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc > --localstatedir=/var/lib CC=x86_64-pc-linux-gnu-gcc --sysconfdir=/etc/wine > --with-curses --with-opengl --with-x --disable-trace --disable-debug > --libdir=/usr/lib32 --build=x86_64-pc-linux-gnu > > so compile ok: > ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info > --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib > --sysconfdir=/etc/wine --with-curses --with-opengl --with-x --disable-trace > --disable-debug --libdir=/usr/lib32 > > bau say: > *** Warning: FreeType is missing. > *** Fonts will not be built. Dialog text may be invisible or unaligned. > That's because it's not finding the freetype2 libs which are in /emul/... --- Look, I've provided you with a fix. If you don't want to use it, then by all means unkeyword wine for amd64. It shouldn't be keyworded amd64 yet anyways AFAIC. --Jeremy
Created attachment 89526 [details] wine-0.9.15.ebuild for amd64 In this ebuild will CC Variable for amd64 = "i686-pc-linux-gnu-gcc"
(In reply to comment #42) > (In reply to comment #41) > > cat compile on amd64 wine-0.9.15 whith ebuild > > This is failt: > > ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man > > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc > > --localstatedir=/var/lib CC=x86_64-pc-linux-gnu-gcc --sysconfdir=/etc/wine > > --with-curses --with-opengl --with-x --disable-trace --disable-debug > > --libdir=/usr/lib32 --build=x86_64-pc-linux-gnu > > > > so compile ok: > > ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info > > --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib > > --sysconfdir=/etc/wine --with-curses --with-opengl --with-x --disable-trace > > --disable-debug --libdir=/usr/lib32 > > > > bau say: > > *** Warning: FreeType is missing. > > *** Fonts will not be built. Dialog text may be invisible or unaligned. > > > > That's because it's not finding the freetype2 libs which are in /emul/... I had same issue with freetype here. This may not be #41's issue, but the reason it wasn't finding the lib for me was because I had a crossdev i686-pc-linux-gnu for use by distcc serving x86 boxes. Here eselect-compiler fixes the issue - I switched the i686-pc-linux-gnu-gcc to be x86_64-pc-linux-gnu-4.1.1/x86-vanilla rather than the crossdev i686-... (and I'm now wondering whether I need the crossdev at all to do distcc for x86 on an amd64 box - perhaps you could let me know off-bug eradicator [or some other toolchain guy]?) But now I feel like I've ended up referring to a side-issue on a workaround in a non-offical ebuild from a half-opened bug...
wine doesnt invoke ld directly and when it does invoke as, it does so with '--32' so forcing the $AS and $LD envvars should not be needed even so, the remaining CBUILD/CHOST forcing is still not acceptable ... ive watched too many crappy multilib implementations come through, i'm not going to watch another one poison the tree
(In reply to comment #45) > wine doesnt invoke ld directly and when it does invoke as, it does so with > '--32' > It only does that if you have CHOST=x86_64-* > so forcing the $AS and $LD envvars should not be needed > even so, the remaining CBUILD/CHOST forcing is still not acceptable ... ive > watched too many crappy multilib implementations come through, i'm not going to > watch another one poison the tree > You were one of the people who were so adimant that CHOST be what determines the package built. I remember YOU were the one who wanted to be able to do: CHOST=i686-pc-linux-gnu emerge mplayer or CHOST=x86_64-pc-linux-gnu emerge mplayer rather than that ABI cruft. Well that is what the goal is, and wine was jumping the gun on providing a compile-from-source 32bit package on amd64 before it was really supported. Yes, the configure script adds the proper LDFLAGS and ASFLAGS but only IF you have the x86_64-* CHOST. It should be compiled with the i686-* CHOST. I'll post something which will hopefully be acceptible to you as a solution until this gets properly fixed with a binutils wrapper for i686-*-as and i686-*-ld on amd64.
Created attachment 89611 [details, diff] wine-0.9.15.ebuild.patch Here's a patch to wine-0.9.15.ebuild which should be acceptible to you. It is just one line, and all the code is in multilib.eclass. It's the only package in the tree which will use it, and I have a comment in there to that effect, so nobody else should jump onboard with this. The proper way to make these packages should be to just set CHOST, but that functionality is not available yet because there are no binutils wrappers for i686-*-{as,ld} on amd64. Make sure that your eclass and profiles are up to date. You should see an ASFLAGS_x86 in profiles/default-linux/amd64/make.defaults, and you should have the multilib_toolchain_setup function in multilib.eclass
Compiles & runs on my setup with patch from comment #47 Alas, Fallout 2 is broken with this release of wine with a lot of fixme:seh:check_no_exec No-exec fault triggered at 0x4ead56, enabling work-around errors. Maybe GCC 4.1.1 related, but probably not related to this bug... *sigh*
> You were one of the people who were so adimant that CHOST be what determines > the package built. I remember YOU were the one who wanted to be able to do: that has *nothing* at all to do with hardcoding this stuff in the ebuild multilib_toolchain_setup is the proper fix i've been pointing to here along ... and you're wrong that wine is the only package which would use it (simply grep for ABI= in the portage tree for other consumers of this)
Yes, but all those don't do it the way wine does. They are all binary packages or glibc (which does set the CHOST this same way). I'll commit this fix then.
no they arent ... if they were binary only packages, then ABI wouldnt matter nestra, snes9x, and zsnes are all from-source packages that utilize ABI=x86
