FS#9883 - GCC 4.3.0 tool chain is producing bad code

Attached to Project: Arch Linux
Opened by Skottish (skottish) - Thursday, 20 March 2008, 03:04 GMT
Last edited by Jan de Groot (JGC) - Friday, 21 March 2008, 20:59 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To No-one
Architecture x86_64
Severity Critical
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Read through this (very convoluted) thread by me. http://bbs.archlinux.org/viewtopic.php?id=45657

This task depends upon

Closed by  Jan de Groot (JGC)
Friday, 21 March 2008, 20:59 GMT
Reason for closing:  Not a bug
Comment by Jan de Groot (JGC) - Thursday, 20 March 2008, 21:13 GMT
I compiled the 20080319-2245 snapshot using our new toolchain on amd64 and rebuilt ffmpeg without any problems. libx264.so links just fine here. The fact that you needed a reboot to get things working again also sounds weird to me. The only thing I do to switch toolchain is cleaning up ccache so I'm sure no old cached objects are used.
Comment by Skottish (skottish) - Thursday, 20 March 2008, 22:18 GMT
I went through this process around 20 times trying to figure this out. Every time I had the exact same results, but only on 64 bit (As I mentioned before, I could reproduce it once on 32 bit).

If I wasn't too unclear, this is the steps to reproduce.

Build x264 from GIT. Don't use any older source snapshots. Then build FFmpeg from subversion (try rev. 12485 because of the new upstream bug). As I said before, Mplayer-svn also did not see x264.

The one particular note that I want to remind you of is what akupenguin said. The error I was getting are conducive of a 32 bit problem, not a 64 bit problem. That call should not have even been in the build, let alone throwing errors.

ccache is something that I wasn't aware of before now. Could it be something there that started this process?
Comment by Tobias Powalowski (tpowa) - Friday, 21 March 2008, 17:23 GMT
fixed with 24.3-4 kernel
Comment by Jan de Groot (JGC) - Friday, 21 March 2008, 20:39 GMT
Ehm, how can a kernel update resolve linking errors?
Comment by Tobias Powalowski (tpowa) - Friday, 21 March 2008, 20:46 GMT
i thought you refered to kernel bug here
Comment by Jan de Groot (JGC) - Friday, 21 March 2008, 20:59 GMT
This is not actually a compiler bug, it's a bug in ffmpeg. I can't reproduce your x264 bug with the x264-git package from AUR. Compiling ffmpeg-svn using x264-git works fine when compiled with gcc 4.3 for the x264 part, but bails out on the swscaler.o error you mentioned on the forum.

Googling for this, I found 3 hits on google, one of them is this:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/64896/focus=64953

"Enabling HAVE_MMX2 for swscale gives an linker error on x86-64 when
compiling as a shared library:"
[..]
"/usr/bin/ld: 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"

It's a bug in ffmpeg because of a recent change. Be aware that ffmpeg is highly unstable development code that doesn't always compile or work. Given the fact that GCC 4.3 is more strict than older compilers, I will close this bug as "Not a bug", as it's not a GCC bug.

Loading...