[Ffmpeg-devel] Error Compiling FFMPEG

Jacob Meuser jakemsr
Tue Jun 7 10:44:33 CEST 2005

On Tue, Jun 07, 2005 at 10:23:30AM +0200, M?ns Rullg?rd wrote:
> Jacob Meuser <jakemsr at jakemsr.com> writes:
> >> >> > /usr/bin/ld: bitstream.o: relocation R_X86_64_32 against `a local
> >> >> > symbol' can not be used when making a shared object; recompile
> >> >> > with -fPIC
> >> >> 
> >> >> Do as it tells you, add --extra-cflags=-fPIC to your configure flags.
> >> >
> >> > but then you get PIC _everywhere_, not just in library objects.
> >> 
> >> Which part of libavcodec is not a library?
> >
> > the user is compiling all of FFmpeg, which includes ffmpeg, ffplay,
> > and ffserver.
> >
> > the --extra-cflags option adds the specified flags the CFLAGS that
> > are used everywhere when compiling FFmpeg.
> >
> > so, using --extra-cflags=-fPIC will add -fPIC to the CFLAGS used to
> > compile ffmpeg, ffplay, and ffserver.
> OK, but why is that a problem?  The reason for not using is -fPIC is
> the sometimes slower code it produces, but that should be
> insignificant for those three programs.  99.99% of the time is spent
> in libavcodec anyway.

it's possible there are no known practical problems, but IMO, FFmpeg's
handling of PIC flags on a whole could be better, technically speaking.

I already posted a patch that adds a LIBOBJFLAGS variable to the
Makefiles.  the reason was to add -fPIC -DPIC only when building
library objects. I have not heard yes or no on that idea.

perhaps I should make a patch for configure to test if PIC is needed for
shared libraries (only used when --enable-shared is used as well)?

<jakemsr at jakemsr.com>

More information about the ffmpeg-devel mailing list