I'll attach a patch to let qemu work with gcc4. You'd need to: a) add qemu-gcc4 to qemu-softmmu-0.8.2-r1 ebuild and remove the gcc4-check. b) replace qemu-gcc4-hacks.patch in qemu-user-0.8.2 with qemu-gcc4 (same patch for both) and remove gcc4-check. Runs fine here.
Created attachment 105759 [details, diff] qemu-gcc4 patch
this patch seems to work just on x86...
i do agree, on amd64 i still get seg faults.
qemu uses gcc for the generation of the application binaries which works with gcc4 if you can browse to the gazillion warnings and still feel comfortable running the binary, and for the opcode generation that won't work in gcc 4 because it is dependent on the way the object code is generated for the compiler to disassemble the instructions in the host CPU and translate between guest and host CPU opcodes, and that format was changed in gcc4 due to improvements in the optimizations. so to make it short, you can compile qemu with gcc4 for the application (i have a patch that does just that), but you still need gcc3 for the opcode generation, and unless qemu finishes their own generator to replace gcc3 or embed gcc3 in their package that means you have to have gcc3 installed in your host anyway so why bother?
Would it be possible to have the ebuild automatically use gcc 3.x if available, then? Using gcc-config before and after emerging qemu (which might be part of a system update) is a bit tedious (and potentially dangerous if you forget to switch it back after the emerge).
(In reply to comment #5) > Would it be possible to have the ebuild automatically use gcc 3.x if available, > then? Using gcc-config before and after emerging qemu (which might be part of a > system update) is a bit tedious (and potentially dangerous if you forget to > switch it back after the emerge). No, it wouldn't... As you've noted, it can pretty much crash lots of stuff.
i do agree with no forcing. i talked with devs they told me a 0.8.3 release is coming between jan and feb (but 90% won't fix gcc4 problem) but 0.8.4 will have gcc4 full support.
upstream already includes an option to autodetect gcc3 which will be available in qemu-0.8.3 (won't work as-is for gentoo though) http://cvs.savannah.nongnu.org/viewcvs/qemu/configure?root=qemu&r1=1.112&r2=1.113 is this is an acceptable "solution"? (at least it is what is supported upstream)
Created attachment 107252 [details, diff] patch from upstream to autodetect gcc3 "backported" to 0.8.2
Comment on attachment 107252 [details, diff] patch from upstream to autodetect gcc3 "backported" to 0.8.2 kept AS-IS from upstream
Created attachment 107255 [details, diff] gentoo specific patch to add autodetection of gcc3 needs to be applied on top of the previous patch from attachment 107252 [details, diff] and should have all possible gcc3 binary names in the system in order of preference. tested in amd64 and x86 stable, will need most likely more names added depending on the currently active build chains / architectures
Created attachment 107257 [details, diff] patch to ebuild for app-emulation/qemu-softmmu-0.8.2-r1 considering that comment 8 is valid and that the two previous patches (or some other versions of them) are applied and copied to "files", this patch changes the ebuild logic so that it can still build in a system that uses gcc4 primarily using gcc3 if autodetected
There was Qemu-0.9.0 released, the new sources compile using gcc 3, but the compilation doesn,t cause already probelems, because qemu uses the "correct" gcc, you need only to have program like gcc32 installed. I'm waiting till qemu 0.9 will be in portage!
Created attachment 112722 [details] my "qemu-softmmu-0.9.0-r1.ebuild" In my system, the patches for gcc4 qemu-0.8.0-gcc4-opts.patch qemu-0.8.0-gcc4-hacks.patch work well for qemu-0.9.0, too . And I can input japanese-words at windows in qemu!
Where can i get qemu-0.8.0-gcc4-opts.patch and qemu-0.8.0-gcc4-hacks.patch ? (In reply to comment #14) > Created an attachment (id=112722) [edit] > my "qemu-softmmu-0.9.0-r1.ebuild" > > In my system, > the patches for gcc4 > qemu-0.8.0-gcc4-opts.patch > qemu-0.8.0-gcc4-hacks.patch > work well for qemu-0.9.0, too . > And I can input japanese-words at windows in qemu! >
(In reply to comment #15) > Where can i get qemu-0.8.0-gcc4-opts.patch and qemu-0.8.0-gcc4-hacks.patch ? They are in the portage-tree ${PORTDIR}/app-emulation/qemu-softmmu/ which need for qemu-softmmu-0.8.1-r1.ebuild . Or may have attached in this page to write qemu-softmmu-0.8.1-r1.ebuild .
new patch available!!! http://qemu-forum.ipi.fi/viewtopic.php?t=2891 and http://lists.gnu.org/archive/html/qemu-devel/2007-08/msg00430.html
It seems that qemu-softmmu 0.9.0-r1 in portage compiles fine with gcc-4 now. So the gcc4 test in the portage ebuild is useless, please remove it. As for the amd64 segfaults, that seems to be a different issue.
Qemu-softmmu-0.9.0-r1 does _not_ compile fine with gcc4. The original ebuild still has the gcc4 check. Without hacking the ebuild as described in the comments above, the compile will not commence.
Ahh, excuse me. I think I must have misinterpreted your comment the wrong way.
Luca, i confirm removing gcc3 check it compiles. can you remove it from portage?
but does it work once built? last time I tried that isn't the case =/
not really stable on amd64 last time i tried but i have several strange patches. but this bug says: "building" so check removed and bug can go fixed. for other issues, upstream :)
Yeah! Eventually I have get qemu compiling working on my x86 system with attached ebuild. So I with to comfirm http://bugs.gentoo.org/attachment.cgi?id=112722 with qemu-0.8.0-gcc4-opts.patch and qemu-0.8.0-gcc4-hacks.patch is working ebuild only for me (all other gcc4 patches I have tried and even gcc-3.4.x does not get worked qemu).
again: does it work once built?
no doesn't always seg. fault (on x86_64)
Luca, however this bug was: "Building" this is closed, it self. the running should go upstream or in a different bug.
Created attachment 144692 [details] Fix gcc4 builds for arm pxa270 emulation Here is another patch, that allows to build qemu-cvs with gcc4 and have a working PXA270 ARM emulation.
Created attachment 144694 [details, diff] Fix gcc4 builds for arm pxa270 emulation Here is another patch, that allows to build qemu-cvs with gcc4 and have a working PXA270 ARM emulation.
*** Bug 231182 has been marked as a duplicate of this bug. ***
Maybe time to mark this as upstream until someone produces a working patch or a SVN-snapshot as it seems like most targets have been ported away from dyngen and should work with gcc4 nowdays. But still maybe that is something for an overlay more then portage?
Created attachment 183445 [details, diff] qemu-0.9.1-gcc4-hacks.patch writen from 0.8.0-hacks I wrote this patch by manual-patching qemu-0.8.0-gcc4-hacks.patch to qemu-0.9.1 source. In my environment(using gcc4), I cannot compile qemu-0.9.1 with this patch. Because some code in qemu-0.9.1 fails compile. To avoid it, I add "--target-list=i386-softmmu" option for configuere to limit compile code. Then I can finish compiling, and WindowsXP in disk image file worked well.
(In reply to comment #32) > Created an attachment (id=183445) [edit] > qemu-0.9.1-gcc4-hacks.patch writen from 0.8.0-hacks > > I wrote this patch by manual-patching qemu-0.8.0-gcc4-hacks.patch to qemu-0.9.1 > source. > In my environment(using gcc4), I cannot compile qemu-0.9.1 with this patch. > Because some code in qemu-0.9.1 fails compile. > To avoid it, I add "--target-list=i386-softmmu" option for configuere to limit > compile code. Then I can finish compiling, and WindowsXP in disk image file > worked well. > Better use an SVN-snap or even better wait about one month and see if the release they have speaked of during Feb at least have made it into rc, as that version will be possible to compile qemu with GCC4, run qemu with GCC4 (as they have ditched dyngen and have something new/better). Patching QEMU-0.9.1 which is using (very) old code, with many bugs that is fixed upstream a long time ago and possible introducing new unsupported bugs are something I think people should not even consider.
So qemu-0.10.0 is released, supposed to work with gcc4 and so on. So is it time to close this bug as wontfix/upstream/whatever, if new qemu does not show up in portage in a couple of days (no zero-day bump-bugs) start a new bug and try to produce a working ebuild for it?
*** Bug 285824 has been marked as a duplicate of this bug. ***
