Summary: | qemu 0.7.0 fails with binutils 2.16 on ppc: Not enough room for program headers | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Grzegorz Kulewski <grzegorz> |
Component: | [OLD] Core system | Assignee: | Luca Barbato <lu_zero> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | abel, sound |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
QEMU CVS ebuild
nasty hack to fix qemu on the ppc |
Description
Grzegorz Kulewski
2004-05-14 12:07:47 UTC
Created attachment 31436 [details]
QEMU CVS ebuild
I used this ebuild but compiling by hand or using release ebuild with i386
target has the same problem.
questions: 1 is the qemu ebuild in portage working? 2 I'll enable the i386 target, I'll check about the alsa lib, sound herd please have a look too 3 which version of binutils are you using? 1. Yes, all ebuilds (official from Portage and mine too) works as long as "i386" is not in targets (and in Portage ebuilds it is not). 2. alsa-lib was compiled only dynamically so I reported bug and it was fixed: to get static version too you must remerge it with static in use so everything is ok (qemu-fast binary must be linked statically) 3. binutils-2.14.90.0.8-r1 - newest in ~x86. I think that the problem is the binutils problem. It can be that linking script in qemu is for older binutils but still my binutils should not give me assertion failed message but some kind of nicer error. PS. You are qemu in Portage maintainer? Will you be interested in adding qemu-cvs ebuild to Portage? (qemu is work in progress and Fabrice often fixes bugs after somebody reports it so people should be able to use CVS easily instead of not very often "official" releases, I think). *** Bug 57998 has been marked as a duplicate of this bug. *** Any progress on this? It does not compile here, neither gcc-3.3.4 nor gcc-3.4 (different errors) I'm tempted to mark it UPSTREAM since there is anything that I can do right now to really fix the issue. You can successfully use qemu but you can't link qemu fast right now, I'll poll more or less regulary the qemu cvs for that issue. move severity to normal, marked the solution as LATER Same problem here. But, according to a post in this thread: http://forums.gentoo.org/viewtopic.php?t=247361 ...this only happens when NTPL is enabled ? (I haven't tried without NTPL, so can't confirm that) Urgh. I did of course mean NPTL, not NTPL =P The same error "Not enough room for program headers" happens on PPC when compiling the arm or the i386 target of QEmu 0.7.0 with softmmu. Can someone reopen this bug? >>> Source unpacked. Install prefix /usr BIOS directory /usr/share/qemu binary directory /usr/bin Manual directory /usr/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /var/tmp/portage/qemu-0.7.0/work/qemu-0.7.0 C compiler gcc make make host CPU powerpc host big endian yes target list i386-user ppc-user i386-softmmu ppc-softmmu x86_64-softmmu gprof enabled no static build no SDL support yes SDL static link yes mingw32 support no Adlib support no FMOD support no kqemu support no The error is gcc -g -Wl,-T,/var/tmp/portage/qemu-0.7.0/work/qemu-0.7.0/ppc.ld -o qemu-i386 elfload.o main.o syscall.o mmap.o signal.o path.o osdep.o thunk.o vm86.o libqemu.a gdbstub.o -lm /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.3-20050110/../../../../powerpc-unknown-linux-gnu/bin/ld: qemu-i386: Not enough room for program headers (allocated 9, need 10) /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.3-20050110/../../../../powerpc-unknown-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[1]: *** [qemu-i386] Error 1 make[1]: Leaving directory `/var/tmp/portage/qemu-0.7.0/work/qemu-0.7.0/i386-user' make: *** [all] Error 1 I have binutils 2.16-r1 # ld --version GNU ld version 2.16 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. I also have gblic 2.3.4.20041102-r1 Luca - I'll take a look at this if you don't mind, see if I can figure it out. Grzegorz - for reference, could you attach your current 'emerge --info', and also the log from emerge qemu (set PORT_LOGDIR=/var/log/portage or somesuch in /etc/make.conf if you don't collect logs). Not a problem, I was able to find thanks to vapier the issue ( wrong macro usage in the ld scripts ), but I cannot find a decent solution ( lack of ldscript knowledge and time to learn ). I you can fix them or the makefiles please send the patch upstream. Created attachment 65201 [details, diff]
nasty hack to fix qemu on the ppc
Oops! I keep getting submitting patches with bugzilla wrong. Anyway, the page: http://www.delorie.com/gnu/docs/binutils/ld_48.html explains that using SIZEOF_HEADERS forces the linker to make assumptions about the size of headers it needs. I assume its discovering it actually need 1 extra header later and thats why it throws this error. My patch just removes that, and replaces it with a nice largish number :) Horrible I know, but I have the linux.img from the linux-test tgz running on my powerbook G4 under linux right now. Oh aye - I also tried a simple statically linked x86 program running on the ppc using 'qemu-i386'. That works fine too. Please commit upstream too Andrew - could you do: $ readelf -l /usr/bin/qmeu-i386 /usr/bin/ls and paste the results? Stale bug I think |