I was working like a madman on FATE’s compilers tonight. Let’s see:
- Added gcc 4.3.4 to all of my Linux configurations (x86_32, x86_64, and PPC), decommissioning 4.3.3
- Added gcc 4.4.1 to Linux/32- and 64-bit x86, decommissioning 4.4.0 (had already done this for PPC some time ago)
- Upgraded the gcc SVN snapshots for all 3 Linux machines
- Upgraded the LLVM SVN snapshots for 32- and 64-bit x86 Linux; this does not solve the build problem for 64-bit (remind me again how LLVM will save us from the tyranny of gcc); Update: solved; thanks for the help in the comments
- Temporarily solved the Intel C Compiler conflict with ccache by disabling ccache when building with icc, thereby crippling build capacity but keeping the builds honest
This all feels like it was way more work than it should have been. Opportunities for improvement abound, starting with my plot for auto-recompiling the gcc and LLVM snapshots and automatically placing the snapshots into service as outlined in a previous post. It should just take an evening if I can get down to it.
I know I have outstanding requests to add LLVM (32- and 64-bit) for Intel Mac. That sounds reasonable, and it would be great to hook up the auto-update script to that LLVM process as well.
PPC64 is also on gcc 4.3.4, so that is quite consistent (though it means other compiler versions get little testing).
I just wished someone would finally investigate what is wrong with rv40 and Sparc/Solaris, that’s one of the few mysteries failures that look like it might be a real bug…
The error you’re getting with clang on x86-64 looks like some sort of issue with ffmpeg configure… the error appears to be correct in saying that the relevant code was in fact not compiled with -fPIC.
That’s because arch is set to generic, maybe we need a generic-pic target in addition (or –enable-pic configure option).
For regular shared x86_64 builds pic is enabled automatically.
If someone can tell me which options I should be using for LLVM/64-bit/Linux, I would be happy to put them into service.
RV40 is failing on Sparc because of unaligned memory accesses. Kostya knows all about it but doesn’t want to fix it. It’s sad.
@Mike:
I’d recommend to get Mans to come up with a configure-based solution, but just add –extra-cflags=”-DPIC -fPIC” –extra-ldflags=”-DPIC -fPIC” should work I think.
@Mans:
Tell me about it, I might have a look (though it would be easier with hardware to verify).
I can easily add a –enable-pic option. The real question, however, is why you’re using –arch=c in the first place.
Regarding alignment, it’s easy to test on my Alpha. You just need to run the test with unaligned access fixup disabled. I can set you up with a login if you want. The errors are caused by calls to fill_rectangle() with unaligned 64-bit destination.
I’m using –arch=c because someone told me to do so in order to make it work. I’m pretty sure it doesn’t build without it. That may not be true, or it may not be true *anymore* and in need of retest. We are always refining and auditing the build options. BTW, thanks for your work in that area, Mans (especially following up on the “Hacks on FATE” thread over of ffmpeg-devel).
Exactly, -arch=c was used because LLVM just can’t handle too much of the inline asm stuff.
In terms of inline asm issues with LLVM, I know ffmpeg is affected by at least http://llvm.org/bugs/show_bug.cgi?id=4118 and http://llvm.org/bugs/show_bug.cgi?id=4668. Other known issues likely to cause problems are http://llvm.org/bugs/show_bug.cgi?id=3812 and http://llvm.org/bugs/show_bug.cgi?id=3800.
I have added a –enable-pic option to configure.
I have updated the 64-bit/Linux/LLVM configuration, replacing –arch=c with –enable-pic. It now compiles and passes all tests except the master regression suite.
You don’t need -enable-pic when you remove the -arch=c, PIC is then already enable automatically. You only need it if you need to keep using -arch=c
You’re right. I removed both the –arch=c and –enable-pic options for 64-bit/Linux/LLVM and it builds and tests fine (save for the full regression suite again).