Re: where do I figure out "relocation R_X86_64_PC32" errors

["vamsi krishna" <vamsi dot krishnak at gmail dot com>]

Hi,

Clearly yuv2rgb.o is not in fPIC mode recompile it with -fPIC.

You can use the following test to verify if a object file is in fPIC
mode or not.

TEST for fPIC:
--------------------

You can use 'objdump -r test.o | grep "R_X86_64_32' if this command
produces some output then this has not been compiled in fPIC mode.

if its a library libtest.a just do a ar -x and find it out.

HTH
Vamsi kundeti

On 9/17/06, sean <seandarcy2@gmail.com> wrote:
> I'm trying to build ffmpeg svn.
>
> It dies:
>
> gcc -shared -Wl,-soname,libswscale.so.0 -Wl,--warn-common
>   -pthread -rdynamic -export-dynamic -Wl,--as-needed
> -Wl,-rpath-link,/usr/src/redhat/BUILD/ffmpeg/libavcodec
> -Wl,-rpath-link,/usr/src/redhat/BUILD/ffmpeg/libavformat
> -Wl,-rpath-link,/usr/src/redhat/BUILD/ffmpeg/libavutil -o
> libswscale.so.0 swscale.o rgb2rgb.o yuv2rgb.o -L../libavutil
> -lavutil -lm -lz -lgsm -lmp3lame -lvorbis -lvorbisenc -logg
> -logg -lxvidcore -lx264 -ldc1394_control -lraw1394 -lfaac
> -lfaad -ldl
> ranlib libswscale.a
> /usr/bin/ld: yuv2rgb.o: relocation R_X86_64_PC32 against
> `mmx_00ffw' can not be used when making a shared object;
> recompile with -fPIC
>
> but yuv2rgb _was_ compiled with -fPIC:
>
> gcc -I.. -I/usr/src/redhat/BUILD/ffmpeg
> -I/usr/src/redhat/BUILD/ffmpeg/libavutil -fPIC -march=k8
> -pthread -g -Wdeclaration-after-statement -Wall -Wno-switch
> -Wdisabled-optimization -Wpointer-arith -Wredundant-decls
> -Winline -O3 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -D_GNU_SOURCE -fPIC -DPIC -c -o
> yuv2rgb.o yuv2rgb.c
>
>
> mmx_00ffw is just a constant in yuv2rgb.c:
>
> uint64_t attribute_used __attribute__((aligned(8)))
> mmx_00ffw = 0x00ff00ff00ff00ffULL;
>
> Any suggestions are appreciated on how to fix this.
>
> But also, is there anyplace this issue is described? For
> instance, does it arise because these are 64 bit ints ?,
> aligned? visibility tags? Any general discussion of this
> issue around? Googling hasn't helped.
>
> sean