[FFmpeg-devel] MinGW-w64 x86_64 spams warning: -fPIC ignored for target

Reimar Döffinger Reimar.Doeffinger at gmx.de
Mon Apr 8 17:06:46 CEST 2013


On Mon, Apr 08, 2013 at 09:12:03AM +0200, Hendrik Leppkes wrote:
> On Mon, Apr 8, 2013 at 6:31 AM, Gianluigi Tiesi <mplayer at netfarm.it> wrote:
> 
> > Hi,
> >
> > By looking at configure script the code for PIC detection checks if
> > __PIC__, __pic__ or PIC are defined (on linux only when passing shared)
> >
> > mingw-w64 on x86_64 targets always defines __PIC__ and __pic__
> > but warns when passing -fPIC as gcc option:
> > warning: -fPIC ignored for target (all code is position independent)
> > [enabled by default]
> >
> > the resulting compilation is somehow unreadable (each gcc call has a
> > warning printed)
> >
> > I've changed configure using this check:
> >
> > if test $target_os != "mingw32"; then
> >     check_cpp_condition stdlib.h "defined(__PIC__) || defined(__pic__) ||
> > defined(PIC)" && enable pic
> > fi
> >
> > but is obiviously ugly
> >
> > do you known a better solution? using a flag filter looks like an overkill
> > to me
> >
> >
> This is not the correct solution. The "pic" option still needs to be
> enabled, because its also used in the codebase to determine if some
> assembler-related things need to be handled differently.
> Instead, the proper solution is to filter out the flag from actually being
> added to CFLAGS
> 
> In any case, i consider this a GCC bug. If an option is always-on, what
> harm is it to explicitly set it? Why warn about this?

In addition, it seems to me there is something wrong with the gcc
config, code is not necessarily position-independent on x86_64.
Is that possibly some hack on MinGW side because (for example) they were
too lazy to fix programs to use -fPIC only when required?


More information about the ffmpeg-devel mailing list