On Sun, 2006-03-26 at 15:44 +0000, Steve Graegert wrote:

Could you please post the complete command line which is used during compilation and the complete compiler/linker output? It's extremely difficult to tell what's going on without it. Oh, please don't forget to post the contents of the environment variables as well (CFLAGS, etc.).

I'm trying to build libfame on 64 bit CFLAGS is set to '-O2 -fmessage-length=0 -fno-unit-at-a-time -fPIC' LDFLAGS is set to '-fPIC' The command line for the linker is gcc -shared -fPIC fame.lo cpuflags.lo fame_profile_mpeg.lo fame_profile_mpeg1.lo fame_profile_mpeg4_simple.lo fame_profile_mpeg4_shape.lo fame_profile_stats.lo fame_encoder_mpeg.lo fame_decoder_mpeg.lo fame_syntax_mpeg1.lo fame_syntax_mpeg4.lo fame_shape.lo fame_rate_simple.lo fame_rate_1param.lo fame_rate.lo fame_monitor.lo fame_motion.lo fame_motion_none.lo fame_motion_fourstep.lo fame_motion_pmvfast.lo fame_malloc.lo -lm -lc -Wl,-soname -Wl,libfame-0.9.so.1 -o .libs/libfame-0.9.so.1.0.0 and the output is /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: fame_encoder_mpeg.lo: relocation R_X86_64_PC32 against `prefetch_C_withmask' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value If more is needed, I can put the entire output from the build up for download

On Sun, 2006-03-26 at 16:28 +0000, Steve Graegert wrote:

How has "fame_encoder_mpeg.lo" been compiled? Try turning the "-fvisibility-hidden" switch off if it is set. Don't know what else to do at the moment :-(

grep visibility famebuild returns no hits, so I don't think it's used. fame_encoder_mpeg.lo was compiled with a lot of options, I put the complete output up at ftp://rydsbo.net/pub/famebuild (40K large text file) thanks for the help

On 3/27/06, Anders Johansson wrote:

On Sun, 2006-03-26 at 18:01 +0200, I wrote:

...

I'm trying to build libfame on 64 bit

I'm getting the same error when trying to compile ffmpeg. This is getting mildly annoying

Hmm, looks like the problem is not directly related to fame. Are you building on AMD64? If so, there are two possibilities: (a) binutils (namely ld) is broken, since it is not able to detect shared objects correctly or (b) you're probably using GCC 4.0 or an older >=3.4.x that hasn't been patched correctly (no, it's not your fault). Try an official GCC (>=3.4.x < 4.x) build and update your binutils appropriately. At least, that's what I'd do next. \Steve

Hi Anders, * Anders Johansson (andjoh@rydsbo.net) [20060326 18:02]:

CFLAGS is set to '-O2 -fmessage-length=0 -fno-unit-at-a-time -fPIC'

Remove the -fno-unit-at-a-time option and all should be well. This is a minor gcc bug which I'll try to verify and and file upstreams when CODE10 is done. Philipp

* Jerry Feldman (gaf@blu.org) [20060327 14:57]:

x86-64. The above error also looks like you are mixing 32-bit objects and 64-bit objects in the same .so.

None of that happening, see my other post. It's 'just' that current gcc fails to inline some static inline functions when passed -fno-unit-at-a-time. Because gcc doesn't see the inline function, the calls remain as unresolved externals in the object files but marked with the wrong reloc type, as 'objdump -r' shows: RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000783 R_X86_64_PC32 prefetch_C_withmask+0xfffffffffffffffc Philipp

On 3/27/06, Philipp Thomas wrote:

On Mon, 27 Mar 2006 10:16:03 +0200, Steve Graegert wrote:

...

(b) you're probably using GCC 4.0 or an older >=3.4.x that hasn't been patched correctly (no, it's not your fault).

What do you mean by "hasn't been patched correctly"?

I've seen users with similar problems that have been solved by building the GCC 3.4.x from gcc.org (official GCC). We were able to track down the problem to a GCC bug which created wrong relocation types with -fvisibility being set, due to a patch that has been incorporated by the vendor. Since you obviously have more details about the issue than we do, I may be wrong. \Steve

* Steve Graegert (graegerts@gmail.com) [20060328 09:06]:

due to a patch that has been incorporated by the vendor.

OK, but I wouldn't have call that "wrongly patched" but rather something like "bug in $VENDOR version of gcc".

Since you obviously have more details about the issue than we do,

Knowing the tools you need to check something like this helps, in this case nm and objdump. nm with either --defined-only or --undefined-only (plus possibly --demangle in both cases when dealing with C++ code) quickly shows symbols present or missing. Non-standard compiler flags like -fno-unit-at-a-time should always be the prime suspects and that's what I tested first. Philipp