QEMU has faster version qemu-fast (target name: i386). As far as I know nobody is able to build it on Gentoo (qemu version CVS or release) while people on other distributions are able to. And ld says about failed assertions so I think that this can be binutils problem. Reproducible: Always Steps to Reproduce: emerge qemu-cvs (see attached ebuild) or compile by hand NOTE: YOU MUST HAVE alsa-lib merged with static in use or you will get other error. Actual Results: gcc -static -Wl,-T,/var/tmp/portage/qemu-cvs-1.5/work/qemu/i386-vl.ld -o qemu-fast vl.o osdep.o block.o monitor.o ide.o ne2000.o pckbd.o vga.o sb16.o dma.o oss.o fdc.o mc146818rtc.o serial.o i8259.o i8254.o pc.o gdbstub.o sdl.o libqemu.a -lm -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread -lm -ldl -laudio -lXt -L/usr/X11R6/lib -lX11 -lXext -laa -L/usr/lib -Wl,-rpath,/usr/lib -laa -lm -L/usr/X11R6/lib -lX11 -lslang -lutil /usr/lib/libSDL.a(SDL_x11gl.o)(.text+0x8b3): In function `X11_GL_LoadLibrary': : warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libaudio.a(ConnSvr.o)(.text+0xa56): In function `MakeTCPConnection': : warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/X11R6/lib/libX11.a(x11trans.o)(.text+0x7de): In function `_X11TransSocketINETConnect': : warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.14.90.0.8 20040114 assertion fail elf.c:3465 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.14.90.0.8 20040114 assertion fail elf.c:3465 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.14.90.0.8 20040114 assertion fail elf.c:3465 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: BFD 2.14.90.0.8 20040114 assertion fail elf.c:3465 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: qemu-fast: Not enough room for program headers (allocated 6, need 8) /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[1]: *** [qemu-fast] Błąd 1 make[1]: Leaving directory `/var/tmp/portage/qemu-cvs-1.5/work/qemu/i386' make: *** [all] Błąd 1 !!! ERROR: app-emulation/qemu-cvs-1.5 failed. !!! Function src_compile, Line 40, Exitcode 2 !!! make failed Expected Results: It should link and merge correctly. Portage 2.0.50-r6 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040420-r0, 2.6.6-mm2) ================================================================= System uname: 2.6.6-mm2 i686 AMD Athlon(tm) processor Gentoo Base System version 1.4.12 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -frename-registers -fno-align-functions -fno-align-labels -fno-align-jumps -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/lib/jboss /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-tbird -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -frename-registers -fno-align-functions -fno-align-labels -fno-align-jumps -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aalib acl acpi alsa atm avi berkdb bonobo cdr crypt cscope cups curl doc dvd encode esd evo flash foomaticdb freetds gb gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile imap imlib innodb jack jack-tmpfs java joystick jpeg junit ladcca lcms libg++ libgda libwww mad maildir mbox mcal mikmod mmx motif mozilla mpeg mpi nas ncurses nls nptl odbc oggvorbis opengl oss pam pdflib perl pic plotutils png postgres ppds prelude python quicktime readline samba sasl sdk sdl slang slp snmp socks5 spell ssl tcltk tcpd tetex tiff truetype unicode usb v4l v4l2 videos wmf wxwindows x86 xml xml2 xmms xosd xv zlib"
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
