cvs update'd half an hour ago... [...] make[1]: Leaving directory `/usr/local/share/builder/pkg/BUILD/MPlayer-20021031/linux' /usr/bin/make -C postproc make[1]: Entering directory `/usr/local/share/builder/pkg/BUILD/MPlayer-20021031/postproc' gcc3 -c -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -o swscale.o swscale.c gcc3 -c -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -o rgb2rgb.o rgb2rgb.c gcc3 -c -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -o yuv2rgb.o yuv2rgb.c ar r libswscale.a swscale.o rgb2rgb.o yuv2rgb.o gcc3 -c -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -o postprocess.o postprocess.c ar r libpostproc.a postprocess.o gcc3 -c -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -fomit-frame-pointer -fPIC -DPIC -o postprocess_pic.o postprocess.c postprocess.c: In function `postProcess_MMX': postprocess_template.c:896: can't find a register in class `GENERAL_REGS' while reloading `asm' make[1]: *** [postprocess_pic.o] Error 1 make[1]: Leaving directory `/usr/local/share/builder/pkg/BUILD/MPlayer-20021031/postproc' make: *** [postproc/libswscale.a] Error 2 [...] At first I thought it could be my setting CFLAGS in RPM build process, so I allowed MPlayer's configure to choose it's own, but to no avail. And I thought I reported something similar recently and someone said it was fixed... BTW: funny thing, which I never noticed before because I always set CFLAGS manually. Well, two things, actually. One: as you can see above, configure chooses -march=i486 -mcpu=i686 for OPTFLAGS even though my CPU is a Duron and is detected: [...] Checking for gcc3 version ... 3.1, ok Checking for CPU vendor ... AuthenticAMD (6:3:1) Checking for CPU type ... AMD Duron(tm) processor Checking for GCC & CPU optimization abilities ... athlon [...] Two: some of the subdirs' Makefiles don't include -Wall in CFLAGS, so lots of warnings go unnoticed. I recently added -Wall to my manually-set CFLAGS and suddenly warnings log jumped from 700 bytes to 18k bytes. I'll try to make a patch next week, when I'm back (going home for the Day of the Dead). -- MPlayer RPMs maintainer: http://www.piorunek.pl/~dominik/linux/pkgs/mplayer/ "The Universe doesn't give you any points for doing things that are easy." -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Hi On Thursday 31 October 2002 01:38, Dominik Mierzejewski wrote: [...]
postprocess_template.c:896: can't find a register in class `GENERAL_REGS'
[...]
At first I thought it could be my setting CFLAGS in RPM build process, so I allowed MPlayer's configure to choose it's own, but to no avail. And I thought I reported something similar recently and someone said it was fixed... it was, thats another one, and its fixed too now
BTW: funny thing, which I never noticed before because I always set CFLAGS manually. Well, two things, actually. One: as you can see above, configure chooses -march=i486 -mcpu=i686 for OPTFLAGS even though my CPU is a Duron and is detected: [...] Checking for gcc3 version ... 3.1, ok
hmm 3.2 is not an option i guess ... [...] Michael
On Thursday, 31 October 2002, Michael Niedermayer wrote:
Hi
On Thursday 31 October 2002 01:38, Dominik Mierzejewski wrote: [...]
postprocess_template.c:896: can't find a register in class `GENERAL_REGS'
[...]
At first I thought it could be my setting CFLAGS in RPM build process, so I allowed MPlayer's configure to choose it's own, but to no avail. And I thought I reported something similar recently and someone said it was fixed... it was, thats another one, and its fixed too now
Just updated from CVS. Sorry, it's still broken. :-( gcc3 -c -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -fomit-frame-pointer -fPIC -DPIC -o postprocess_pic.o postprocess.c postprocess.c: In function `postProcess_MMX': postprocess_template.c:2505: can't find a register in class `GENERAL_REGS' while reloading `asm' postprocess_template.c:2588: can't find a register in class `GENERAL_REGS' while reloading `asm' postprocess_template.c:2505: can't find a register in class `GENERAL_REGS' while reloading `asm' postprocess_template.c:2588: can't find a register in class `GENERAL_REGS' while reloading `asm' make[1]: *** [postprocess_pic.o] Error 1 make[1]: Leaving directory `/usr/local/share/builder/pkg/BUILD/MPlayer-20021031/postproc' make: *** [postproc/libswscale.a] Error 2 [...]
Checking for gcc3 version ... 3.1, ok hmm 3.2 is not an option i guess ...
Sorry, no. I couldn't find any gcc3-3.2 packages that would install on my RH7.3 box. I tried to build some myself using gcc3-3.1 and gcc-3.2 source RPMs and failed. If you have some reproducible bugs in RH's gcc3-3.1 I'd be happy to report them through bugzilla.redhat.com, because this gcc3 is supported by RH. -- MPlayer RPMs maintainer: http://www.piorunek.pl/~dominik/linux/pkgs/mplayer/ "The Universe doesn't give you any points for doing things that are easy." -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Hi On Thursday 31 October 2002 03:15, Dominik Mierzejewski wrote:
On Thursday, 31 October 2002, Michael Niedermayer wrote:
Hi
On Thursday 31 October 2002 01:38, Dominik Mierzejewski wrote: [...]
postprocess_template.c:896: can't find a register in class `GENERAL_REGS'
[...]
At first I thought it could be my setting CFLAGS in RPM build process, so I allowed MPlayer's configure to choose it's own, but to no avail. And I thought I reported something similar recently and someone said it was fixed...
it was, thats another one, and its fixed too now
Just updated from CVS. Sorry, it's still broken. :-( gcc3 -c -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -fomit-frame-pointer -fPIC -DPIC -o postprocess_pic.o postprocess.c postprocess.c: In function `postProcess_MMX': postprocess_template.c:2505: can't find a register in class `GENERAL_REGS' while reloading `asm' postprocess_template.c:2588: can't find a register in class `GENERAL_REGS' while reloading `asm' postprocess_template.c:2505: can't find a register in class `GENERAL_REGS' while reloading `asm' postprocess_template.c:2588: can't find a register in class `GENERAL_REGS' while reloading `asm' make[1]: *** [postprocess_pic.o] Error 1 make[1]: Leaving directory `/usr/local/share/builder/pkg/BUILD/MPlayer-20021031/postproc' make: *** [postproc/libswscale.a] Error 2
[...]
Checking for gcc3 version ... 3.1, ok
hmm 3.2 is not an option i guess ...
Sorry, no. I couldn't find any gcc3-3.2 packages that would install on my RH7.3 box. I tried to build some myself using gcc3-3.1 and gcc-3.2 source RPMs and failed. If you have some reproducible bugs in RH's gcc3-3.1 I'd be happy to report them through bugzilla.redhat.com, because this gcc3 is supported by RH. it depends upon the definition of a bug, (gcc 3.2 seems to have no problem with the pp code, but gcc 3.1 seems to have troubble with it, its not strictly a bug as noone ever said that if there are 6 registers available (esp is the stack pointer and ebx is that stupid PIC pointer, they arent available) that gcc must be able to use 6 in an asm()
anyway i disabled the .so compilation now, if no --enable-shared-pp is used so this should be solved allthough dont expect to be able to compile libpostproc.so with gcc 3.1 and changing all code to use fewer registers isnt really possible Michael
On Thursday, 31 October 2002, Michael Niedermayer wrote: [...]
Sorry, no. I couldn't find any gcc3-3.2 packages that would install on my RH7.3 box. I tried to build some myself using gcc3-3.1 and gcc-3.2 source RPMs and failed. If you have some reproducible bugs in RH's gcc3-3.1 I'd be happy to report them through bugzilla.redhat.com, because this gcc3 is supported by RH. it depends upon the definition of a bug, (gcc 3.2 seems to have no problem with the pp code, but gcc 3.1 seems to have troubble with it, its not strictly a bug as noone ever said that if there are 6 registers available (esp is the stack pointer and ebx is that stupid PIC pointer, they arent available) that gcc must be able to use 6 in an asm()
anyway i disabled the .so compilation now, if no --enable-shared-pp is used so this should be solved allthough dont expect to be able to compile libpostproc.so with gcc 3.1 and changing all code to use fewer registers isnt really possible
Fair enough. By the time we'll need libpostproc.so, I'll probably have switched to RH8.x with gcc-3.2. -- MPlayer RPMs maintainer: http://www.piorunek.pl/~dominik/linux/pkgs/mplayer/ "The Universe doesn't give you any points for doing things that are easy." -- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
participants (2)
-
Dominik Mierzejewski -
Michael Niedermayer