[FFmpeg-cvslog] r20497 - trunk/configure

David Conrad lessen42
Mon Nov 16 01:37:12 CET 2009


On Nov 15, 2009, at 2:43 PM, M?ns Rullg?rd wrote:

>>>>> 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.).
> 
> Does not adding that flag break anything.  If not, screw OSX and
> remove the hack.  Nobody is forced to use OSX anyway, so they have
> only themselves to blame if it's slow.

It breaks gcc 4.2 and newer, which I see as unlikely to be fixed ever given that the gcc darwin maintainers work on llvm instead nowadays.

The only two hosts in the section that care about PIC are OpenBSD and Darwin, OpenBSD unconditionally enables PIC, and the check is broken on Darwin. The only other reason I can see it might not be safe is check_cc, but that's already used before the arch section.

Not running the check on Darwin at all is another option, since PIC is always enabled by default, but it's uglier.



More information about the ffmpeg-cvslog mailing list