You are not logged in.
---correction for correct package name---
My understanding about this stuff is very limited. I'm not filing a bug report until I know that it's a bug and not user error.
libtool-2.2.2 from testing seems to be producing bad shared objects. I built x264-git using the entire tool chain in testing (gcc 4.3.0 etc). I went to rebuild ffmpeg-svn afterwards and it couldn't find x264 even though it's binary ran fine on it's own. The effect was reminiscent of what happens when extern C{} isn't called when compiling between C++ to C, but both of these programs are pure C. Regressing libtool works for building ffmpeg-svn on my 32 bit box, but not my 64 bit box.
Just for fun, here's the output of config.err for x264 from ffmpeg:
check_lib x264.h x264_encoder_open -lx264 -lm
check_header x264.h
check_cpp
BEGIN /tmp/ffmpeg-conf-5262-12800-11030.c
1 #include <x264.h>
2 int x;
END /tmp/ffmpeg-conf-5262-12800-11030.c
gcc -march=native -mtune=native -O2 -pipe -fPIC -fomit-frame-pointer -pthread -E -o /tmp/ffmpeg-conf-30235-12800-2480.o /tmp/ffmpeg-conf-5262-12800-11030.c
In file included from /tmp/ffmpeg-conf-5262-12800-11030.c:1:
/usr/include/x264.h:32:4: warning: #warning You must include stdint.h or inttypes.h before x264.h
check_func x264_encoder_open
check_ld
check_cc
BEGIN /tmp/ffmpeg-conf-5262-12800-11030.c
1 extern int x264_encoder_open();
2 int main(void){
3 x264_encoder_open();
4 }
END /tmp/ffmpeg-conf-5262-12800-11030.c
gcc -march=native -mtune=native -O2 -pipe -fPIC -fomit-frame-pointer -pthread -c -o /tmp/ffmpeg-conf-30235-12800-2480.o /tmp/ffmpeg-conf-5262-12800-11030.c
gcc -o /tmp/ffmpeg-conf-533-12800-18464 /tmp/ffmpeg-conf-30235-12800-2480.o -lz -pthread -lm -la52 -lfaac -lfaad -lmp3lame -lm -ltheora -logg -lvorbisenc -lvorbis -logg -lx264 -lm
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib/libx264.so: undefined reference to `x264_pixel_sa8d_8x8_mmxext'
collect2: ld returned 1 exit status
ERROR: x264 not found
Last edited by skottish (2008-03-21 18:44:46)
Offline
Nobody? This one is going to be an issue...
Offline
gcc 4.3.0
Apparently need to apply kernel patch.
Offline
It's a bug in the source. Check this:
http://forum.doom9.org/showthread.php?t=97531&page=10
Same bug on x86_64 windows...
Offline
Apparently need to apply kernel patch.
I'll give this one a shot.
It's a bug in the source.
from 2006? In x264? That's crazy talk!
I can reproduce this on both architectures as I said before. 64 bit won't allow me to roll back libtool without GCC also, 32 will. That's the only difference. Also, the "ERROR: x264 not found" line speaks volumes.
----EDIT----
Hmmm... I could reproduce this error yesterday on 32 bit with libtool-2.2.2. I can't today. I upgraded the entire testing tree again, and everything is building fine. It looks like you're much closer to the mark JGC than I thought. I'll file with x264 and see if they know anything.
Last edited by skottish (2008-03-19 14:53:49)
Offline
Bump.
Whatever is happening is bad. akupenguin, x264's lead developer, said this about my error message:
x86_64 doesn't have nor use x264_pixel_sa8d_8x8_mmxext. So find out where the reference is, and that's the bug.
This is not good. I can't find any reference to this in ffmpegs source code (or anything like it). Nor can I compile ffmpeg anymore. Removing the x264 reference, ffmpeg fails at:
swscale.o: relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
swscale.o: could not read symbols: Bad value
These errors use to be fixable by adding this to the configure lines, and ffmpeg does it automatically now, but I did it all the same:
--extra-ldflags=-Wl,-Bsymbolic
I rolled back gcc, gcc-libs, binutils, libtool, cairomm, libsigc++2.0, glibmm, and gtkmm, and that doesn't help. It's also useful to note that mplayer-svn can't see x264 at compile time either.
So, either or all of these things are happening:
a) There's something that upgraded that borked this system, and left residual files somewhere
b) There's something that needs to be rolled back that I missed
c) I'm the unfortunate victim of a bunch of coincidences
d) My computer is possessed by the devil and should be burned at the nearest stake
Any opinions?
******************************************
Don't want to bump anymore. The GCC 4.3.0 tool chain is at fault here. I had to revert all it's libraries and restart the computer to get a useful shared object out of x264. The second FFmpeg error turned out to be an upstream coincidence.
Last edited by skottish (2008-03-20 12:19:59)
Offline
From JGC in flyspray:
fixed with 24.3-4 kernel
Thank you for following up on this. My lack of deep knowledge makes it tricky for me to help with something this subtle. I really appreciate the time.
--EDIT--- (last time I hope)
It seems that the conversation continued at flyspray. It was decided that the x264 problem isn't one. It may be because of my building MPlayer from subversion (libavcodec) that I was seeing the problem there. I knew the second FFmpeg problem was upstream before hand, but it was confirmed. (Quick personal note, I've built FFmpeg at least a hundred times from subversion, and this is only the third hard break I've seen)
http://bugs.archlinux.org/task/9883
Last edited by skottish (2008-03-21 21:45:01)
Offline