[FFmpeg-cvslog] r20497 - trunk/configure

[Alexander Strange]

On Nov 15, 2009, at 11:29 AM, Reimar D?ffinger wrote:

> On Sun, Nov 15, 2009 at 12:02:39PM +0000, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>>> On Sun, Nov 15, 2009 at 01:58:12AM -0500, Alexander Strange wrote:
>>>> The compiler defaults to PIC, so that check runs 'enable pic'.
>>>> 
>>>> After that, -mdynamic-no-pic, which turns it off again, is under ! 'enabled_any pic shared', so it's not added.
>>> 
>>> Hm. It was specifically for that check I put this before it, however I
>>> misread the condition.
>> 
>> What does that flag do anyway?
> 
> info gcc says:
> `-mdynamic-no-pic'
>     On Darwin and Mac OS X systems, compile code so that it is not
>     relocatable, but that its external references are relocatable.  The
>     resulting code is suitable for applications, but not shared
>     libraries.
> 
> Basically it's the closest you can get to non-PIC on OSX I think.
> However, as the docs say it only can be done for a static build (or
> more precisely for the binaries), however if you do not create a PIE
> binary there is no point to respect --enable-pic IMO, or is there
> something I miss?

x86-32 can use it for anything, but some dynamic linker optimizations won't work so it uses more memory.
x86-32 can even use -fno-pic (otherwise none of the asm would work), but it's not supported so it tends to find linker bugs.

x86-64 is always PIC no matter what the flags, and PPC is accurate to the docs.

So without an --enable-pie, there's no other reason to not use the flag.

>>>> Maybe it shouldn't be using the same variable for PIC being
>>>> detected and the user specifically requesting it, but that won't
>>>> fix this check, which either needs to not run for Darwin or to run
>>>> after the flag is added.
>>> 
>>> Why is adding that flag conditional on PIC anyway?
>> 
>> IIRC it was supposed to do something allowing non-pic code in shared
>> libs.  Now that doesn't make much sense if, as you say, PIC is always
>> on with that compiler.
>> 
>> So which way is it?
> 
> No, it is supposed to allow avoiding some of the cost of PIC for binaries
> by using PIC only where necessary (I think something like ebx must have
> a specific value when calling system functions etc.).
> _______________________________________________
> ffmpeg-cvslog mailing list
> ffmpeg-cvslog at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-cvslog