I was using wine-1.1.13 ebuild before the Jan/28/09 update to the same version and now certain apps will not launch.. I have tried 1.1.12 and everythings normal as before. Its whatever was changed in the past week that has broken this. The only good example i can give is with Steam and Left 4 Dead If you try to start the game it will not run.. Previously it worked flawlessly. Reproducible: Always Steps to Reproduce: Decribed above
Also simply copying the 1.1.12 ebuild and removing the ssp patch line and then renaming to 1.1.14 solved the issue So its definitly something with the ebuild
Please post your `emerge --info' here too.
(In reply to comment #1) > Also > > simply copying the 1.1.12 ebuild and removing the ssp patch line and then > renaming to 1.1.14 solved the issue Um, so you're using the unstable ebuilds and 1.1.14 fixes your problems? # ChangeLog for app-emulation/wine # Copyright 1999-2009 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/app-emulation/wine/ChangeLog,v 1.246 2009/01/30 20:34:03 vapier Exp $ *wine-1.1.14 (30 Jan 2009) 30 Jan 2009; Mike Frysinger <vapier@gentoo.org> +wine-1.1.14.ebuild: Version bump. Fixed.
No that ebuild is the problematic one. Yes if i use the ebuild provided by portage since(1/30/09) it messes things up. However sinmply renaming the 1.1.12 build to 1.1.14 and removing a patch fixes everything I am preparing all the info now .. ebuilds, confs, emergeinfos
Created attachment 180424 [details] wine-1.1.14.ebuild-custom-ebuild.txt
Created attachment 180425 [details] config.log-custom-ebuild.txt
Created attachment 180427 [details] emerge-info-custom-ebuild.txt
Created attachment 180429 [details] wine-1.1.14.ebuild-portage-ebuild.txt
Created attachment 180431 [details] config.log-portage-ebuild.txt
Created attachment 180432 [details] emerge-info-portage-ebuild.txt
Ive attached everything above the custom-ebuild ones are mine that work from a 1.1.12 ebuild renamed to 1.1.14 and removing the ssp patch. the portage-ebuild ones are straight from the 1/30/09 portage. Hope we can figure this out
Just tried 1.1.15 and same issue until i patch the ebuild... Very annoying
Ive tried all combinations of flags i could think of.. No resolution
I can confirm this bug, Half-Life based games through Steam won't work without it, it just exits after loading. I first reported this as a bug with wine+xfce upstream before I found this bug report (http://bugs.winehq.org/show_bug.cgi?id=17349) Quick walkthrough of what I did to fix it (following Shawn's advice): cd /usr/portage/app-emulation/wine grep -v 'ssp' wine-1.1.12.ebuild > wine-1.1.15.ebuild ebuild wine-1.1.15.ebuild digest emerge -av wine My use-flags are: app-emulation/wine-1.1.15 USE="X alsa cups gecko jpeg ncurses opengl samba -dbus -esd -gnutls -hal -jack -lcms -ldap -nas -oss -scanner -xml" Thanks to Shawn for figuring this out.
Doesnt work in 13 14 or 15
added the mulitlib line back in http://sources.gentoo.org/app-emulation/wine/wine-1.1.13.ebuild?r1=1.7&r2=1.8 http://sources.gentoo.org/app-emulation/wine/wine-1.1.14.ebuild?r1=1.2&r2=1.3 http://sources.gentoo.org/app-emulation/wine/wine-1.1.15.ebuild?r1=1.1&r2=1.2 http://sources.gentoo.org/app-emulation/wine/wine-1.1.16.ebuild?r1=1.1&r2=1.2 http://sources.gentoo.org/app-emulation/wine/wine-9999.ebuild?r1=1.33&r2=1.34
Sadly readding the multilib doesnt fix it... Left4Dead & GarrysMod(i just purchased recently) doesnt launch.. It will only launch when steam is closed and you manually enter the launch command, however valve put an end to running games w/o steam running.. Maybe its just me now? Hopefully the others can confirm or dismiss my claims.
In short: there are bugs that should be reported for the distro and there are some that are upstream-only. This is the second kind. While I have never used Steam, I vaguely recall some upstream posts, that, combined with ebuild diffs, seem to point in the direction of wine_gecko, which has changed version from 0.9.0 in 1.1.12 to 0.9.1 in 1.1.13. So, this may not be amd64 related - and if it's both wine_gecko and amd64 related, it's definitely upstream bug.
for me its not amd64 related.. it cant be gecko either because the 1.1.13 ebuild was working before it was updated to handle useflags differently.
the fastest way to resolve this is to look at the wine-1.1.13 history and test each revision: http://sources.gentoo.org/app-emulation/wine/wine-1.1.13.ebuild then report exactly which revs work and which revs fail
OK, this bug is not fixed, neither is it a problem upstream. As I barely mentioned (you can see it if you check out my bogus bugreport at winehq), I did a full regression test between 1.1.12 and 1.1.13 with manually compiling from git source (using the instructions provided at winehq) , and the problem is nonexistant upstream. I emerged 1.1.16 recently, and the problem is still there.
1.1.16 can also be fixed in the usual way; cd /usr/portage/app-emulation/wine grep -v 'ssp' wine-1.1.12.ebuild > wine-1.1.16.ebuild ebuild wine-1.1.16.ebuild digest emerge -av wine works perfectly.
(In reply to comment #20) > the fastest way to resolve this is to look at the wine-1.1.13 history and test > each revision: > http://sources.gentoo.org/app-emulation/wine/wine-1.1.13.ebuild > > then report exactly which revs work and which revs fail > Everything before and including 1.4 work for 1.1.13 1.1.13 - 1.1 = PASS 1.1.13 - 1.2 = PASS 1.1.13 - 1.3 = PASS 1.1.13 - 1.4 = PASS 1.1.13 - 1.5 = FAIL 1.1.13 - 1.6 = FAIL 1.1.13 - 1.7 = FAIL 1.1.13 - 1.8 = FAIL >1.1.13 = FAIL :(
OOPS 1.1.12 not 1.1.13
(In reply to comment #24) > OOPS 1.1.12 not 1.1.13 > oh jeez lol im confusing myself.. yeah 1.1.13 not 1.1.12 ignore comment #24
YAY! I got it working!! Reproduce: 1.)Uninstall wine 2.)Install latest wine in upstream. 3.)Reboot(IMPORTANT) 4.)Start Steam 5.) L4D! USE FLAGS=X alsa cups dbus gecko hal jpeg lcms ldap ncurses opengl samba xml -esd -jack -nas -oss -scanner Hopefully someone can confirm aswell before we close this
so you're saying that this works (assume all ebuilds are from portage tree): emerge -C wine emerge wine reboot <wine works now>
seems so...
that seems sad ... do other people see this behavior ? the install path of wine libraries do move around, but it shouldnt result in behavior like this ...
Shawn, are you sure you didn't do the grep -v ssp maneuver? The USE-flags you're referencing does not match wine 1.1.16 at all... If you emerge --sync and emerge -pv wine the use flags should contain all these: [ebuild R ] app-emulation/wine-1.1.16 USE="X alsa cups gecko jpeg ncurses opengl png%* samba ssl%* -dbus -esd -gnutls -hal -jack -lcms -ldap -nas -oss -scanner -win64% -xcomposite% -xinerama% -xml" 0 kB
those are the flags EiX reports.. Prolly doesnt show them right Yes im sure its upstream.
Unless im crazy, ill check again Im confusing myself to death here lol
There's been three days, reached a verdict yet? ..
If you still have this problem (and you are completely sure it's not a wine_gecko problem, please, post your 'emerge --info', specifically compiler and CFLAGS.
I did: > emerge -avC wine > emerge -av wine (version 1.1.17) > reboot Still does not work! Starting any Half-Life based games still just quits to desktop. Installed with use-flags: [ebuild R ] app-emulation/wine-1.1.17 USE="X alsa cups dbus gecko hal jpeg ncurses opengl png samba ssl xcomposite xinerama -esd -gnutls -jack -lcms -ldap -nas -oss -scanner -win64 -xml" 0 kB And still, as usual, this problem can be fixed by doing the grep -v ssp-thing with version 1.1.12. My emerge --info: Portage 2.1.6.10 (default/linux/x86/2008.0, gcc-4.3.3, glibc-2.9_p20081201-r2, 2.6.28-gentoo-r3 i686) ================================================================= System uname: Linux-2.6.28-gentoo-r3-i686-Intel-R-_Core-TM-2_Duo_CPU_T7500_@_2.20GHz-with-glibc2.0 Timestamp of tree: Tue, 24 Mar 2009 08:45:02 +0000 app-shells/bash: 4.0_p10 dev-java/java-config: 1.3.7-r1, 2.1.7 dev-lang/python: 2.5.4-r2 dev-util/cmake: 2.6.2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.3-r1 sys-apps/sandbox: 1.5 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19.1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /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 /etc/udev/rules.d" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="en nb" MAKEOPTS="-j4" 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="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/arcon /usr/local/portage/layman/wschlich-testing /usr/local/portage/layman/java-overlay /usr/local/portage/local" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aac aalib acl acpi alsa berkdb bzip2 cjk cli cracklib crypt cups dbus dell dri flac fortran gdbm gif gpm gtk hal iconv isdnlog java5 java6 jpeg jpeg2k kdeenablefinal kdehiddenvisibility midi mmx mp3 mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre perl png ppds pppd python readline reflection samba session spl sse sse2 sse3 ssl ssse3 startup-notification svg sysfs tcpd tiff truetype unicode vorbis wavpack x86 xcomposite xfce xinerama xorg xscreensaver xv xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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 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" ELIBC="glibc" INPUT_DEVICES="keyboard synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en nb" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I'd like you to test my theory: please, leave that ssp patch and add flag-o-matic to inherit, then: 1. add 'append-flags -fno-inline-small-functions' 2. if that works, add 'append-flags -fno-guess-branch-probability' instead of that
Thanks for your reply, but could you be even more verbose? What text should I put where, and should I do the grep -v 'ssp' maneuver at all? Please give a step-by-step tutorial so that I don't make any unnecessary mistakes :)
As it's my little theory, here's what I want you to do: 1. take the tree ebuild 2. in the 'inherit' line add 'flag-o-matic' 3. in src_configure block, right before econf line add: a) first time - 'append-flags -fno-inline-small-functions' b) second time - 'append-flags -fno-inline-small-functions' (only one of those lines should be there at a time) I simply want to see, if your problem is not a duplicate of certain other bugs (both wine and gentoo, actually coming from the compiler). One more thing: test that "grep fix" with 1.1.17 too, as I'm not fully convinced, that this is not wine_gecko related.
That second time was meant to be 'append-flags -fno-guess-branch-probability', of course.
Thanks, I'll get right to it.. tomorrow :) Just wanted to say that the > grep -v 'ssp' wine-1.1.12.ebuild > wine-1.1.17.ebuild procedure still works.
No, I meant that you should see, if removing that ssp patch from 1.1.17 tree ebuild works, cause I still think this might be related to wine_gecko 0.9.0 -> 0.9.1 move.
Wine 1.1.12 is the last ebuild with the ssp-patch integrated, so there's no "grep fix" with wine >1.1.12-ebuilds. I've done your test with -fno-inline-small-functions (The output from compile showed me that the flag got included). Unfortunately, it did not work. Later today I'll test with -fno-guess-branch-probability. Shawn, what's the difference between these versions which you tested? > 1.1.13 - 1.4 = PASS > 1.1.13 - 1.5 = FAIL You haven't replied yet to how it went with your 1.1.16-testing/use flags-uncertainties...
-fno-guess-branch-probability is tested, failed. I also tried changing $GV from 0.9.1 to 0.9.0, still didn't work. Also tried to exclude the winegcc-patch, still didn't work. Only thing that's working is grep -v 'ssp' wine-1.1.12.ebuild > wine-1.1.17.ebuild I'll see if I can find what offending lines there is in wine-1.1.17.ebuild, but for me this still is a big conundrum.
Same procedure with wine 1.1.18. > emerge --sync > cd /usr/portage/app-emulation/wine > grep -v 'ssp' wine-1.1.12.ebuild > wine-1.1.18.ebuild > sed -i 's/0.9.0/0.9.1/' wine-1.1.18.ebuild # For updating gecko to 0.9.1 > ebuild wine-1.1.18.ebuild digest I think it's weird that this bug hasn't received any more attention. Are there really not so many people playing Half-Life/Counter-Strike through wine with Gentoo? This bug should affect everyone doing that, and I'm interested if anyone has found out what's doing this. I have this problem on all of my Gentoo setups...
Same procedure with wine 1.1.19.
see Comment 20
Shawn Bruce answered that question in Comment #23, didn't he? That this patch http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/wine/wine-1.1.13.ebuild?r1=1.4&r2=1.5 did it...? I would try to mess around if it werent for that I really do not know ebuilds well... Just for the record: If I download wine-1.1.19.tar.bz2, and then use the same ./configure as wine-1.1.19 would do in portage _without_ the grep/sed procedure, and then make/install, then the bug is _not_ reproduced. So the error can't be the selected useflags, it has to be something with the ebuild (or portage itself, for all I know..).
you have to read all of his comments, not just the first one
The failing revision is 1.2 and not 1.5. > Add USE="png ssl win64" and convert USE flags to $(use_with) #255250 by Johan Verrept. > (Portage version: 2.2_rc20/cvs/Linux 2.6.28 x86_64) http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/wine/wine-1.1.13.ebuild?r1=1.1&r2=1.2 I suspect the migration to EAPI 2 and/or the convertion to $(with_use) has something to do with this bug, since I can use the 1.1.12-ebuild on any wine version and it works. As said before, when I manually compile wine-1.1.19 from sources outside from portage, but with the same ./configure as an untouched wine-1.1.19-ebuild would use, it works too, so I really doubt it has something to do with added use-flags. Hope this bug gets reopened.
hey all still dun work :|
Weird thing is, when compiling this with amd64 multilib-profile on a machine with fglrx as driver, it works. The machines not working is regular 32 bit-profile with nvidia-drivers (don't know if drivers has anything to do with this).
Another update: Still the same computer: nvidia-drivers, default 2008.0 profile, newest nvidia-drivers: Building wine 1.1.21 through Portage and running any game from Steam doesn't work. Using 1.1.12-ebuild as base or manual building from source still does. Issue is not replicated on ~amd64 multilib-profile.
The minimum patch that got >=app-emulation/wine-1.1.13 working for me was to add the strip-flags back in. I'm not sure why it was dropped but it seems like things are mis-compiled with -O3. -O2 works. I tracked it down further to -ftree-vectorize which is one of the features turned on by -O3. An alternative to strip-flags that also works for me is append-cflags -fno-tree-vectorize This is with gcc-4.3.4 (latest stable x86)
restored the strip-flags behind USE=custom-flags
