Arch Linux

skottish

Forum Fellow

From: Here

Registered: 2006-06-16

Posts: 7,880

libtool-2.2.2 producing bad shared objects? [SOLVED]

---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)

skottish

Forum Fellow

From: Here

Registered: 2006-06-16

Posts: 7,880

Re: libtool-2.2.2 producing bad shared objects? [SOLVED]

Nobody? This one is going to be an issue...

brebs

Member

Registered: 2007-04-03

Posts: 3,066

Re: libtool-2.2.2 producing bad shared objects? [SOLVED]

gcc 4.3.0

Apparently need to apply kernel patch.

---

Improve your desktop responsiveness and font rendering and ALSA sound and BusyBox init

JGC

Developer

Registered: 2003-12-03

Posts: 1,658

Re: libtool-2.2.2 producing bad shared objects? [SOLVED]

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...

skottish

Forum Fellow

From: Here

Registered: 2006-06-16

Posts: 7,880

Re: libtool-2.2.2 producing bad shared objects? [SOLVED]

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)

skottish

Forum Fellow

From: Here

Registered: 2006-06-16

Posts: 7,880

Re: libtool-2.2.2 producing bad shared objects? [SOLVED]

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)

skottish

Forum Fellow

From: Here

Registered: 2006-06-16

Posts: 7,880

Re: libtool-2.2.2 producing bad shared objects? [SOLVED]

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)