[MPlayer-dev-eng] Linking mplayer fails

Alex Romosan romosan at sycorax.lbl.gov
Tue Apr 2 00:59:56 CEST 2013


Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:

> On 1 Apr 2013, at 20:36, Alex Romosan <romosan at sycorax.lbl.gov> wrote:
>> Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:
>> 
>>> No, that will completely break it! The point is to detect whether the
>>> (assembler) code we create must be PIC, not forcing the compiler to
>>> generate PIC code!
>>> PIC is not something we should _ever_ enable by default as your
>>> suggestion does, but only if we have to.
>> 
>> so how exactly is your test supposed to work? why would gcc just
>> generate position independent code if you don't ask it to?
>
> Due to profiles (used by gentoo hardened), due to PIE (on
> architectures where this implies PIC), due to environments that
> mandate PIC (OSX without -mdynamic-no-pic I believe), due to compiler
> options (-fPIC in --extra-cflags, though that could be considered a
> user error).
> I might have missed a few.

exactly, but your were not passing -fpie before. in case you forgot this
is what was happening:

 #if !(defined(__PIC__) || defined(__pic__) || defined(PIC))
 #error condition not true: defined(__PIC__) || defined(__pic__) || defined(PIC)
 #endif
 int main(void) { return 0; }

 cc -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith
 -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes
 -Wdisabled-optimization -Wno-pointer-sign
 -Wdeclaration-after-statement -std=3Dgnu99
 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=3D200112
 -D_XOPEN_SOURCE=3D600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=3Dnative
 -mtune=3Dnative -pipe -ffast-math -fomit-frame-pointer
 -fno-tree-vectorize /tmp/mplayer-configure-5914-5626/tmp.c -ffast-math
 -o /tmp/mplayer-configure-5914-5626/tmp -lm
 /tmp/mplayer-configure-5914-5626/tmp.c:3:2: error: #error condition not true: defined(__PIC__) || defined(__pic__) || defined(PIC)


 Result is: no

so, tell me. which flag in there tells the compiler to generate pic
code? the only reason the test worked for you was that on osx pic seems
to be enabled by default. now when you do the test you actually do pass
-fpie so (not surprisingly) you find that pic is enabled:

============ Checking for PIC ============


#if !(defined(__PIC__) || defined(__pic__) || defined(PIC))
#error condition not true: defined(__PIC__) || defined(__pic__) || defined(PIC)
#endif
int main(void) { return 0; }

cc -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize /tmp/mplayer-configure-28034-21361/tmp.c  -fpie   -ffast-math -fpie -pie   -o /tmp/mplayer-configure-28034-21361/tmp  -lm


Result is: yes 

from the gcc 4.7 man page:

  -fPIC
      If supported for the target machine, emit position-independent
      code, suitable for dynamic linking and avoiding any limit on the
      size of the global offset table.  This option makes a difference on
      the m68k, PowerPC and SPARC.

      Position-independent code requires special support, and therefore
      works only on certain machines.

      When this flag is set, the macros "__pic__" and "__PIC__" are
      defined to 2.

so _if supported_ then create position independent code. at the same
time:

  -fpie
  -fPIE
      These options are similar to -fpic and -fPIC, but generated
      position independent code can be only linked into executables.
      Usually these options are used when -pie GCC option will be used
      during linking.

so you still haven't really explained how you thought the test might
work without telling the compiler to generate pic code either by using
-fpic or -fpie other than it just works for you on osx because it's
enabled by default so i won't really bother to think through this at
all.


--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |


More information about the MPlayer-dev-eng mailing list