Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
bin/sh ../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -I../lib/dec -I../lib/enc -Wall -Wno-parentheses -O2 -march=native -mtune=native -pipe -ggdb -c -o libtheora_la-dct_decode_mmx.lo `test -f 'enc/x86_32/dct_decode_mmx.c' || echo './'`enc/x86_32/dct_decode_mmx.c i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -I../lib/dec -I../lib/enc -Wall -Wno-parentheses -O2 -march=native -mtune=native -pipe -ggdb -c enc/x86_32/dct_decode_mmx.c -fPIC -DPIC -o .libs/libtheora_la-dct_decode_mmx.o enc/x86_32/dct_decode_mmx.c: In function 'FilterHoriz__mmx': enc/x86_32/dct_decode_mmx.c:94: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' enc/x86_32/dct_decode_mmx.c:96: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' enc/x86_32/dct_decode_mmx.c:94: error: 'asm' operand has impossible constraints enc/x86_32/dct_decode_mmx.c:96: error: 'asm' operand has impossible constraints make[2]: *** [libtheora_la-dct_decode_mmx.lo] Error 1 emerge --info Portage 2.1.4_rc3 (default-linux/x86/2007.0/desktop, gcc-4.2.2, glibc-2.7-r0, 2.6.23-gentoo-r2 i686) ================================================================= System uname: 2.6.23-gentoo-r2 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Timestamp of tree: Tue, 27 Nov 2007 19:16:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.2-r1 dev-lang/python: 2.4.4-r4, 2.5.1-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r2 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -mtune=native -pipe -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -mtune=native -pipe -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks installsources metadata-transfer parallel-fetch sandbox sfperms splitdebug strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://gentoo.blueyonder.co.uk http://gentoo.tiscali.nl/ http://gentoo.mirror.solnet.ch http://pandemonium.tiscali.de/pub/gentoo/" LANG="en_GB.UTF-8" LC_ALL="en_GB.UTF-8" LINGUAS="en_GB en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/musicbrainz /usr/portage/local/layman/emacs /usr/portage/local/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi aim alsa apache2 arts audiofile avi bash-completion berkdb bitmap-fonts bluetooth bonobo browserplugin bzip2 bzlib cairo caps cddb cdparanoia cdr cjk cli cracklib crypt cups curl dbus directfb doc dri dts dvd dvdr dvdread eds emacs emboss encode esd ethereal evo examples exif expat fam fbcon ffmpeg firefox flac foomaticdb fortran ftp gcj gd gdbm gif glut gmp gnome gnutls gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml guile hal iconv icq idn ieee1394 imagemagick imlib ipv6 isdnlog jabber jack java javascript jbig jce jpeg jpeg2k junit kde kdehiddenvisibility kerberos ladspa lcms ldap leim libgda libnotify libsamplerate lirc lm_sensors logrotate lua mad matroska mbox midi mikmod milter mime mmap mmx mng modplug mono mp3 mpeg mpi mplayer msn mudflap musepack ncurses nls nptl nptlonly nsplugin odbc offensive ogg oggvorbis openal opengl openmp oscar oss pam pcntl pcre pdf perl png postgres ppds pppd profile pulseaudio python qt3 qt3support qt4 quicktime readline recode reflection ruby sasl sdl seamonkey session sharedmem sndfile snmp sockets sox speex spell spl sqlite3 sse sse2 ssl svg sysvipc tcl tcltk tcpd tetex theora threads tiff tk truetype truetype-fonts type1-fonts uicktime unicode usb v4l v4l2 vim-syntax vorbis win32codecs wmf wxwindows x264 x86 xface xine xml xml2 xorg xulrunner xv xvid yahoo zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB en" LIRC_DEVICES="asusdh" USERLAND="GNU" VIDEO_CARDS="radeon vesa fbdev vga" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Try without -ggdb in your CFLAGS, but if that doesn't help you can as workaround enable USE="pic" to disable asm.
I see, try also adding -fomit-frame-pointer in CFLAGS.
*** Bug 200552 has been marked as a duplicate of this bug. ***
+ 27 Nov 2007; Samuli Suominen <drac@gentoo.org> + files/libtheora-1.0_beta2-flags.patch: + Restore -fomit-frame-pointer wrt #200549. in cvs..
Well, this still fails exactly the same even w/ -fomit-frame-pointer if -fforce-addr is used in CFLAGS. Also, did someone report this upstream?
(In reply to comment #5) > Well, this still fails exactly the same even w/ -fomit-frame-pointer if > -fforce-addr is used in CFLAGS. Also, did someone report this upstream? > Manually removing -fforce-addr was the only way to get libtheora-1.0_beta2-r1 to build here for me.
*** Bug 202505 has been marked as a duplicate of this bug. ***
Reopening, fails w/ CFLAGS="-march=pentium3 -O0 -pipe" as well (Bug 202505) and there really should be something done upstream about this.
Created an attachment (id=138713) [details] updated pic-fix for theora 1.0-beta2 i've updated the current pic-fix patch so that the compiler doesn't run out of registers even when the frame pointer is used. note that this is replacement of the current in-portage patch, if you need a separate one then just interdiff them.
thanks, but it still fails with -fforce-addr here :/ though it gains one register, so we dont need -fomit-framepointer to be forced anymore. /bin/sh ../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -I../lib/dec -I../lib/enc -Wall -Wno-parentheses -fomit-frame-pointer -march=athlon-xp -O2 -pipe -fforce-addr -c -o libtheora_la-dct_decode_mmx.lo `test -f 'enc/x86_32/dct_decode_mmx.c' || echo './'`enc/x86_32/dct_decode_mmx.c i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -I../lib/dec -I../lib/enc -Wall -Wno-parentheses -fomit-frame-pointer -march=athlon-xp -O2 -pipe -fforce-addr -c enc/x86_32/dct_decode_mmx.c -fPIC -DPIC -o .libs/libtheora_la-dct_decode_mmx.o enc/x86_32/dct_decode_mmx.c: In function `FilterHoriz__mmx': enc/x86_32/dct_decode_mmx.c:93: error: can't find a register in class `GENERAL_REGS' while reloading `asm' enc/x86_32/dct_decode_mmx.c:95: error: can't find a register in class `GENERAL_REGS' while reloading `asm' make[2]: *** [libtheora_la-dct_decode_mmx.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -I../lib/dec -I../lib/enc -Wall -Wno-parentheses -fomit-frame-pointer -march=athlon-xp -O2 -pipe -fforce-addr -c dec/state.c -o libtheora_la-state.o >/dev/null 2>&1 make[2]: Leaving directory `/var/tmp/portage/media-libs/libtheora-1.0_beta2-r1/work/libtheora-1.0beta2/lib' make[1]: *** [all-recursive] Error 1 It seems the "m" constraints become "r" with -fforce-addr (if I understand it correctly), so the good old x86 is still starving registers there...
(In reply to comment #10) > thanks, but it still fails with -fforce-addr here :/ > though it gains one register, so we dont need -fomit-framepointer to be forced > anymore. and that's what i intended to fix, sorry if i wasn't clear. see below. > It seems the "m" constraints become "r" with -fforce-addr (if I understand it > correctly), so the good old x86 is still starving registers there... according to http://gcc.gnu.org/gcc-4.3/changes.html : Command-line changes * -fforce-addr has been removed. It is now ignored by the compiler. so IMHO there's little to point to attempt to fix these issues when they're going to automatically go away next year anyway (not to mention that in cases like this it may very well be impossible, at least without extensive rewriting of the inline asm).
(In reply to comment #11) > according to http://gcc.gnu.org/gcc-4.3/changes.html : > > Command-line changes > * -fforce-addr has been removed. It is now ignored by the compiler. eh, crap, that was for m68k, the general change involves only -fforce-mem. still, is there any point in supporting -fforce-addr here?
(In reply to comment #12) > still, is there any point in supporting -fforce-addr here? Shrug, lets just filter it on x86 and be done with it; was mainly after fixing the -fomit-frame-pointer thing as forcing this makes debugging pretty much impossible on x86.
(In reply to comment #13) > (In reply to comment #12) > > still, is there any point in supporting -fforce-addr here? > > Shrug, lets just filter it on x86 and be done with it; was mainly after fixing > the -fomit-frame-pointer thing as forcing this makes debugging pretty much > impossible on x86. not impossible but one will surely have to delve into asm for that. if there're other packages filtering no-frame-pointer i can take a look, just open a bug and CC me.
-O0 shouldn't be allowed for other reasons...
(In reply to comment #15) > -O0 shouldn't be allowed for other reasons... Luca, PLEASE do educate me on this. "Back in the day" and for the longest time, I used -O2. Since I've started participating in debugging a F/OSS project, their developers always complained about my backtraces looking "really ugly" and they attributed it to my -O2. Earlier this year, I gave SourceMage a try. When I gave up and came back to Gentoo, I started using -O0 in my CFLAGS in order to "be a better debugger". I know that -O* is a shorthand method for specifying a range of other various gcc flags, but not the nitty gritty details. Soooo. Why should -O0 not be allowed, and what should I use? -O1? -O2? -Os? Thanks!
So, - Apply attached patch - filter-flags -fforce-addr - replace-flags -O0 -O2 - Remove forcing -fomit-frame-pointer from current patch And be done with it?
> - Apply attached patch done > - filter-flags -fforce-addr not done > - replace-flags -O0 -O2 not done > - Remove forcing -fomit-frame-pointer from current patch done I've succesfully built it with -O0 -fforce-addr with gcc 4.2.2 However, I had issue on hardened with gcc 3.4 iirc. I'd bet this is a gcc bug. We could filter some flags but this would not be a good idea imho as its more gcc's fault than the package's. Moreover, gcc 4.3 changes.html seems wrong as -fforce-addr seems to have been removed not only for m68k, according to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713 and: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01651.html The funny thing is that it's gone for that exact reason... And thanks a lot for the updated patch ;)
*** Bug 212194 has been marked as a duplicate of this bug. ***
Both -fforce-addr and -frename-registers should be filtered: enc/x86_32/dct_decode_mmx.c:93: erreur: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ enc/x86_32/dct_decode_mmx.c:95: erreur: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’
Samuli, Alexis, what the problem to filter flags based on gcc version? We have old compilers in the tree and will have for some time (year, may be even more?). Not filtering -fforce-addr breaks our hardened users as hardened still means gcc-3.4 in Gentoo or is that possible to use newer gcc somehow? If that's impossible (and it is AFAIK), please, add something like this into ebuild: inherit toolchain-funcs flag-o-matic if [[ $(gcc-version) == 3.4 ]] ; then filter-flags -fforce-addr -frename-registers fi
After irc discussion with aballier, the code suggested in #21 is added to ebuild and this bug is FIXED in the tree.
*** Bug 215938 has been marked as a duplicate of this bug. ***
(In reply to comment #22) > After irc discussion with aballier, the code suggested in #21 is added to > ebuild and this bug is FIXED in the tree. > Your workaround seems to fail wrt bug 215938.
Ok, obviously I misread bug and nobody told me :/ Now filtering out -fforce-addr and -frename-registers on x86.
libtheora-1.0_beta3 is now in portage, but it still has the line: use x86 && filter-flags -fforce-addr -frename-registers #200549 can you guys try removing that line from _beta3.ebuild and testing again? leaving it there untested is not a option :)
Created an attachment (id=150102) [details] scanelf-textrel with beta3 beta3 builds correctly with both -fforce-addr and -frename-registers but it has text relocations.
And relocation exists in either case, with or without filter-flags. So at the moment it's safe to drop that line, but seems that new bug should be filled.
(In reply to comment #28) > And relocation exists in either case, with or without filter-flags. So at the > moment it's safe to drop that line, but seems that new bug should be filled. > Someone needs to do that then. I don't have access to x86 hardware running Gentoo. 18 Apr 2008; Samuli Suominen <drac@gentoo.org> libtheora-1.0_beta3.ebuild: TEXTRELs are back and filter-flags isn't needed anymore according to bug #200549, comment #28. Updated PIC patch is needed.
Bug 218267.
