At least with multilib-portage, i do add the related flags for the target to the already set user flags, so that e.g. $CFLAGS additionally gets $CFLAGS_x86 appended, when compiling for x86. On amd64, there was the addition of *FLAGS_amd64 some weeks ago, which means, that those flags, especially -m64 for C{,XX}FLAGS, are now included. wine does explicitly build the 32bit target with -m32, but this is added before user *FLAGS, so the -m64 there overrides the -m32 included earlier. Proposed fix: Move the needed flags after the user *FLAGS, so that they do override anything set there. Tested versions: wine-1.3.2 and wine-1.3.35 Please also fix wine-1.3.2 beside later versions, since later versions refuse to run a good amount of my windows apps. emerge --info: Portage 2.2.0_alpha81-r1 (hardened/linux/amd64/10.0, gcc-4.5.3, glibc-2.14.1-r1, 2.6.32-gentoo-r39 x86_64) ================================================================= System uname: Linux-2.6.32-gentoo-r39-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-gentoo-2.1 Timestamp of tree: Sa 3. Dez 16:06:39 CET 2011 app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.6-r1, 2.7.2-r3 dev-util/cmake: 2.8.6-r4 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.7 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1-r1 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.3-r1 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.14.1-r1 Repositories: gentoo enlightenment sunrise multilib Meins Installed sets: @enlightenment, @fonts, @system ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/home/thomas/daten/distfiles" EMERGE_DEFAULT_OPTS="--keep-going" FEATURES="assume-digests binpkg-logs collision-protect distlocks ebuild-locks fixlafiles metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="" GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="de_DE.UTF-8@euro" LDFLAGS="-Wl,--as-needed -Wl,--hash-style=gnu" LINGUAS="de" MAKEOPTS="-j5 --load-average=8" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/home/thomas/daten" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/enlightenment /usr/local/portage/layman/sunrise /usr/local/portage/layman/multilib-portage /usr/local/portage" SYNC="cvs://tommy@cvs.gentoo.org:/var/cvsroot" USE="3dnow X alsa amd64 berkdb cli cracklib crypt cups custom-cflags custom-cxxflags custom-optimization cxx dri gpm hardened java5 java6 justify mmx modules mudflap multilib ncurses nls nptl nptlonly nsplugin ogg openmp pam pax_kernel pppd readline scanner session sse sse2 ssl sysfs tcpd unicode urandom v4l vorbis xorg zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" MULTILIB_ABIS="amd64 x86" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" multilib_abi="amd64 x86" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
wine already takes care of its own multilib needs. look at the ABI handling in there. this builds 32bit and 64bit binaries on amd64 systems.
Created attachment 296643 [details] build.log for wine-1.3.35 by default, it does handle it, yes, but look at this line (from build.log): x86_64-pc-linux-gnu-gcc -m32 -c -I/home/thomas/daten/portage/app-emulation/wine-1.3.35/work/wine-1.3.35/dlls/actxprxy -I. -I/home/thomas/daten/portage/app-emulation/wine-1.3.35/work/wine-1.3.35/include -I../../include -D__WINESRC__ -DWINE_REGISTER_DLL -DPROXY_DELEGATION -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -march=native -O2 -pipe -g -m64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o actxprxy_servprov_p.o actxprxy_servprov_p.c It is building win32, so the -m32 is ok, but the user CFLAGS (-march=native -O2 -pipe -g -m64) contain -m64 (which is from the added CFLAGS_amd64=-m64 from profiles). The later -m64 does overwrite the previous -m32. To not let something like that happening, the -m32 should be moved after the user *FLAGS, so that they cannot overwrite this switch
i don't see this as a bug in wine
How about adding something like "filter-flags -m64 -m32 -mx32" to the ebuild like in glibc?
that doesn't scale. random ebuilds should not need to know how ABI internals. if the multilib eclass ABI toolchain selection isn't working, then look into fixing that instead.
(In reply to comment #5) > that doesn't scale. random ebuilds should not need to know how ABI internals. > > if the multilib eclass ABI toolchain selection isn't working, then look into > fixing that instead. To be fair, wine's build system is somewhat unusual, and short of special-casing a [[ ${CATEGORY}/${PN} = app-emulation/wine ]] check, I don't know how multilib-portage should detect it. I have added "filter-flags -m64 -m32 -mx32" calls to the wine-1.4_rc1 ebuild. Thomas, could you check whether that's sufficient for multilib-portage purposes? >*wine-1.4_rc1 (28 Jan 2012) > > 28 Jan 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > +wine-1.4_rc1.ebuild: > Version bump, see http://www.winehq.org/announce/1.4-rc1 for the > announcement. Filter -m64 -m32 -mx32 flags for multilib-portage (bug #395615, > thanks to Thomas Sachau).
(In reply to comment #6) no, filtering ABI flags isn't acceptable. i already posted a way forward without copying & pasting crap between ebuilds.
(In reply to comment #7) > i already posted a way forward without copying & pasting crap between ebuilds. Where did you post it? If it was somewhere else, please give a link. If you are referring to comment #5, that seemed rather unclear (I don't understand what fix to multilib.eclass would allow multilib-portage to know that wine needs different ABI flag handling from 99% of the ebuilds in the tree, but maybe I am missing something obvious?)
(In reply to comment #8) wine does not encode any ABI-specific details other than saying "i want ABI=XXX". any internal details beyond that do not belong in the wine ebuild. it's either the multilib portage code or the multilib.eclass.
(In reply to comment #6) > I have added "filter-flags -m64 -m32 -mx32" calls to the wine-1.4_rc1 ebuild. Thanks. I dug your ebuild out of the CVS history and successfully updated Wine for the first time in two months.
(In reply to comment #9) > wine does not encode any ABI-specific details other than saying "i want > ABI=XXX". any internal details beyond that do not belong in the wine ebuild. > it's either the multilib portage code or the multilib.eclass. OK, let's be reasonable. There is a *small* number of packages in the tree that need to build binaries for a specific ABI which is not the arch's default ABI. (I can think of gcc, glibc, grub, wine, and nspluginwrapper; probably there are a few others.) For these packages, multilib-portage needs to be prevented from doing its usual *FLAGS magic. Now, there are a few ways of achieving this goal: 1. special-case the amd64 target to not do *FLAGS magic. Advantage: simplest solution for the amd64/x86 multilib. Disadvantage: ugly (arch-specific workarounds in package manager), breaks the x32/amd64/x86 multilib. 2. move multilib-portage's flag mangling down to the toolchain level, and have it activated depending on the value of ABI env variable. Advantage: looks elegant at first glance. Disadvantage: at least for wine, will require two "ABI=..." statements in every src_* function (might be worked around with an eclass); lots of work and testing needed on toolchain maintainers' part; will take time for modified toolchain packages to get to users; risk of accidentally breaking things. 3. filter-flags in each src_* function in affected ebuilds. Advantage: works right now. Disadvantage: ugly (duplicated code which will all need to be modified if e.g. additional flags will need to be filtered in the future). 4. patch the makefile in affected packages so multilib-portage's flag magic happens to work. Advantage: works right now. Disadvantage: adds to package maintainers' workload; may prevent users from legitimately setting certain flags. 5. blacklist in multilib-portage code. Advantage: works right now. Disadvantage: ugly, does not scale, fails with overlays. 6. some kind of a switch in affected ebuilds' global scope, for example a global variable (MULTILIB_PORTAGE_FLAGS=no) or a new eclass (inherit multilib-portage-flags-ignore). Disadvantage: needs a patch to multilib-portage. Advantage: scalable and reasonably non-ugly. Of these alternatives, 6 imho seems the most promising. @vapier, could you agree not to veto adding such an inherit or global variable to wine ebuilds? @tommy, binki, could you agree to make the needed change to portage-multilib so 6 could work?
(In reply to comment #9) > (In reply to comment #8) > > wine does not encode any ABI-specific details other than saying "i want > ABI=XXX". any internal details beyond that do not belong in the wine ebuild. > it's either the multilib portage code or the multilib.eclass. The wine ebuild does not, but the wine build system does. The configure script does add -m32/-m64 to CC/CXX vars directly. Since the compiler of course comes before the compiler flags, those flags are then overwritten by the flags in CFLAGS/CXXFLAGS. So the best way to avoid any issues here would be to change the behaviour of the build system of wine, so that it does append the needed flags to CFLAGS/CXXFLAGS instead of CC/CXX.
(In reply to comment #11) the number of consumers in the tree is irrelevant. if it is more than one, then it belongs in multilib.eclass (or some common location). random packages should not be hardcoding an arbitrary list of ABI flags as that's a PITA to maintain.
Created attachment 300571 [details] additionally append ABI flags to *FLAGS vars from IRC: <tetromino> winegcc is a C program which *at runtime* execs a command. This command begins with the string defined in the CC macro. The CC macro is defined as -DCC="\"$(CC)\"" in the relevant makefile. In other words, the CC variable that is defined at build time will be used by winegcc at runtime. The CFLAGS variable that is defined at built time will *not* be used by winegcc at runtime. Instead the runtime value of CFLAGS will be used by winegc Because of that part, this means either the appended patch or removing all lines appending ABI flags from configure and appending ABI flags with multilib eclass to CC/CXX and CFLAGS/CXXFLAGS/LDFLAGS
(In reply to comment #14) If I understood the conclusion of the #gentoo-dev conversation last week correctly, there were no objections to the final version of this patch. It has now been added to 1.4_rc2; I hope that this finally resolves the issue. >*wine-1.4_rc2 (05 Feb 2012) > > 05 Feb 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > +wine-1.4_rc2.ebuild, +files/wine-1.4_rc2-multilib-portage.patch, > wine-9999.ebuild: > Bump, see http://www.winehq.org/announce/1.4-rc2 for the announcement. Add > patch by Thomas Sachau to (hopefully) finally fix bug #395615.
Hm, sorry did I miss some thing? Wine 1.4_rc6 still hits here this problem???
make[1]: Entering directory `/var/tmp/portage/app-emulation/wine-1.4_rc6/work/wine32/dlls/acledit' x86_64-pc-linux-gnu-gcc -m32 -c -I/var/tmp/portage/app-emulation/wine-1.4_rc6/work/wine-1.4-rc6/dlls/acledit -I. -I/var/tmp/portage/app-emulation/wine-1.4_rc6/work/wine-1.4-rc6/include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -O2 -march=core2 -msse4.1 -msse4.2 -mcx16 -mpopcnt -msahf -pipe -m32 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o main.o /var/tmp/portage/app-emulation/wine-1.4_rc6/work/wine-1.4-rc6/dlls/acledit/main.c ../../../wine64/tools/winegcc/winegcc -m32 -B../../../wine64/tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared /var/tmp/portage/app-emulation/wine-1.4_rc6/work/wine-1.4-rc6/dlls/acledit/acledit.spec main.o -o acledit.dll.so ../../libs/port/libwine_port.a -Wl,-O1 -Wl,--as-needed -m32 /usr/bin/ld: Relocatable linking with relocations from format elf64-x86-64 (main.o) to format elf32-i386 (acledit.O4NRvw.o) is not supported winebuild: /usr/bin/ld failed with status 1 winegcc: ../../../wine64/tools/winebuild/winebuild failed make[1]: *** [acledit.dll.so] Fehler 2 make[1]: Leaving directory `/var/tmp/portage/app-emulation/wine-1.4_rc6/work/wine32/dlls/acledit' make: *** [dlls/acledit] Fehler 2 make: Leaving directory `/var/tmp/portage/app-emulation/wine-1.4_rc6/work/wine32'
(In reply to comment #17) This looks like a different problem (your output does not show the mixture of -m32 and -m64 flags that caused the failure reported by Thomas Sachau). Please file a new bug and attach your complete build log to it.
(In reply to comment #18) > (In reply to comment #17) > > This looks like a different problem (your output does not show the mixture > of -m32 and -m64 flags that caused the failure reported by Thomas Sachau). > Please file a new bug and attach your complete build log to it. done, https://bugs.gentoo.org/show_bug.cgi?id=407929
