Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 200549 - media-libs/libtheora-1.0_beta2 compilation fails w/o -fomit-frame-point and w/ -fomit-frame-pointer -fforce-addr and w/ -O0
Summary: media-libs/libtheora-1.0_beta2 compilation fails w/o -fomit-frame-point and w...
Status: VERIFIED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: media-video herd
URL:
Whiteboard:
Keywords:
: 200552 202505 212194 215938 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-27 20:32 UTC by Graham Murray
Modified: 2008-04-18 14:12 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
updated pic-fix for theora 1.0-beta2 (libtheora-1.0_beta2-pic-fix.patch,4.47 KB, patch)
2007-12-17 09:46 UTC, PaX Team
Details | Diff
scanelf-textrel with beta3 (scanelf-textrel.log,3.14 KB, text/plain)
2008-04-17 20:08 UTC, Olivier Rolland
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Graham Murray 2007-11-27 20:32:17 UTC
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
Comment 1 Samuli Suominen gentoo-dev 2007-11-27 20:47:41 UTC
Try without -ggdb in your CFLAGS, but if that doesn't help you can as workaround enable USE="pic" to disable asm.
Comment 2 Samuli Suominen gentoo-dev 2007-11-27 20:48:29 UTC
I see, try also adding -fomit-frame-pointer in CFLAGS.
Comment 3 Samuli Suominen gentoo-dev 2007-11-27 20:53:37 UTC
*** Bug 200552 has been marked as a duplicate of this bug. ***
Comment 4 Samuli Suominen gentoo-dev 2007-11-27 20:55:17 UTC
+  27 Nov 2007; Samuli Suominen <drac@gentoo.org>
+  files/libtheora-1.0_beta2-flags.patch:
+  Restore -fomit-frame-pointer wrt #200549.

in cvs..
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2007-12-08 17:21:29 UTC
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?
Comment 6 Jonathan Heaney 2007-12-12 18:41:35 UTC
(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.
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2007-12-16 19:22:36 UTC
*** Bug 202505 has been marked as a duplicate of this bug. ***
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2007-12-16 19:24:02 UTC
Reopening, fails w/ CFLAGS="-march=pentium3 -O0 -pipe" as well (Bug 202505) and there really should be something done upstream about this.
Comment 9 PaX Team 2007-12-17 09:46:44 UTC
Created attachment 138713 [details, diff]
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.
Comment 10 Alexis Ballier gentoo-dev 2007-12-18 11:10:03 UTC
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...
Comment 11 PaX Team 2007-12-19 09:46:09 UTC
(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).
Comment 12 PaX Team 2007-12-19 09:49:33 UTC
(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?
Comment 13 Jakub Moc (RETIRED) gentoo-dev 2007-12-19 09:56:47 UTC
(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.

Comment 14 PaX Team 2007-12-19 10:58:37 UTC
(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.
Comment 15 Luca Barbato gentoo-dev 2007-12-19 15:52:47 UTC
-O0 shouldn't be allowed for other reasons...
Comment 16 Jason S. 2007-12-19 18:47:52 UTC
(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!
Comment 17 Samuli Suominen gentoo-dev 2007-12-21 18:05:33 UTC
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?

Comment 18 Alexis Ballier gentoo-dev 2008-01-03 15:47:55 UTC
> - 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 ;)
Comment 19 Samuli Suominen gentoo-dev 2008-03-03 15:31:11 UTC
*** Bug 212194 has been marked as a duplicate of this bug. ***
Comment 20 Olivier Rolland 2008-03-04 07:44:04 UTC
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’
Comment 21 Peter Volkov (RETIRED) gentoo-dev 2008-03-10 15:19:29 UTC
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
Comment 22 Peter Volkov (RETIRED) gentoo-dev 2008-03-10 15:30:34 UTC
After irc discussion with aballier, the code suggested in #21 is added to ebuild and this bug is FIXED in the tree.
Comment 23 Samuli Suominen gentoo-dev 2008-04-03 14:17:17 UTC
*** Bug 215938 has been marked as a duplicate of this bug. ***
Comment 24 Samuli Suominen gentoo-dev 2008-04-03 14:18:19 UTC
(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.
Comment 25 Peter Volkov (RETIRED) gentoo-dev 2008-04-03 18:27:29 UTC
Ok, obviously I misread bug and nobody told me :/
Now filtering out -fforce-addr and -frename-registers on x86.
Comment 26 Samuli Suominen gentoo-dev 2008-04-17 12:21:36 UTC
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 :)
Comment 27 Olivier Rolland 2008-04-17 20:08:56 UTC
Created attachment 150102 [details]
scanelf-textrel with beta3

beta3 builds correctly with both -fforce-addr and -frename-registers but it has text relocations.
Comment 28 Peter Volkov (RETIRED) gentoo-dev 2008-04-18 08:15:09 UTC
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.
Comment 29 Samuli Suominen gentoo-dev 2008-04-18 13:58:38 UTC
(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.
Comment 30 Samuli Suominen gentoo-dev 2008-04-18 14:12:26 UTC
Bug 218267.