Emerging wine-0.9.16 fails on 'oleview' (./wine-0.9.16/programs/oleview/) I'm not entirely sure but I think this is a different bug then this one: http://bugs.gentoo.org/show_bug.cgi?id=138296 (wine-0.9.16 fails to emerge with eselect-compiler/gcc-config-1.x), in either case I don't have eselect-compiler at all, but do have gcc-config-1.x: shogoki ~ # eix gcc-config\|eselect-compiler * app-admin/eselect-compiler Available versions: ~2.0.0_rc1-r6 ~2.0.0_rc2 ~2.0.0_rc2-r1 Installed: none Homepage: http://www.gentoo.org/ Description: Utility to configure the active toolchain compiler * sys-devel/gcc-config Available versions: 1.3.13-r3 ~2.0.0_rc1 Installed: 1.3.13-r3 Homepage: http://www.gentoo.org/ Description: Utility to configure the active toolchain compiler
Created attachment 90899 [details] Output of `emerge wine'
Created attachment 90900 [details] Output of `emerge --info'
Try with *sane* C[XX]FLAGS (like -march=pentium-m -O2 -pipe -fomit-frame-pointer)
well thank you for your very constructive input Jacub, I very much appreciate it! You know, instead of looking /just/ at CFLAGS, you /might/ actually take a look at a bug first, before shouting nonsense. The only reason that it 'WORKSFORYOU' is because of your pussy CFLAGS. Don't get me wrong, I agree that solving bugs as a /result/ of CFLAGS is wrong, but not every bug is neccesarily CFLAGS related (even if you may think it is). This is a simple case where the linker can't find some symbols or whatever. Most (at least in my experience) CFLAGS bugs will either occur when compiling (-frename-registers sometimes breaks inline assembly for example) or when running a program (This, I have yet to observe however). I'm not saying it's not possible, I just find it highly unlikely since I've been compiling wine with these CFLAGS for a _long_ time, and never before has the emerge failed (so there :p). But enough of that, let's get back to the topic at hand. This appears to be a KNOWN BUG: check http://www.mail-archive.com/wine-devel@winehq.org/msg28499.html for details. I've included a patch for both the ebuild and Makefile in question. It's probably not the best way to solve it since it just adds $(LIBUNICODE) to Makefile.in rather then via the configure script, but it 'WORKSFORME'. If anyone has a better alternative I'd be glad to hear it :)
Created attachment 91016 [details, diff] wine-0.9.16.ebuild.patch
Created attachment 91017 [details, diff] wine-0.9.16-oleview-libunicode.patch
