[FFmpeg-cvslog] r20497 - trunk/configure
David Conrad
lessen42
Mon Nov 16 14:15:20 CET 2009
On Nov 16, 2009, at 7:01 AM, M?ns Rullg?rd wrote:
> David Conrad <lessen42 at gmail.com> writes:
>
>> 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.
>
> Now I'm totally confused. Can someone please complete the table below:
I counted -fPIC to include -DPIC in cppflags, all compilation failures due to this are noted and need only -DPIC to work.
-mdynamic-no-pic overrides -fPIC and warns about it.
Also, MANGLE means that x86-32 is never fully PIC.
x86-32, gcc < 4.2
static shared -fPIC -mdynamic-no-pic | works
--------------------------------------------------+--------
1 x | N (needs -DPIC for swscale)
2 x x | Y (PIC)
3 x x | Y (non-PIC)
4 x x x | Y (non-PIC)
5 x | N (needs -DPIC for swscale)
6 x x | Y (PIC)
7 x x | Y (non-PIC)
8 x x x | Y (non-PIC)
x86-32, gcc >= 4.2 (compilation failures due to gcc bugs with inline asm)
static shared -fPIC -mdynamic-no-pic | works
--------------------------------------------------+--------
1 x | N
2 x x | N
3 x x | Y
4 x x x | Y
5 x | N
6 x x | N
7 x x | Y
8 x x x | Y
x86-64 (flags ignored, always PIC)
static shared -fPIC -mdynamic-no-pic | works
--------------------------------------------------+--------
1 x | N (needs -DPIC)
2 x x | Y
3 x x | Y
4 x x x | Y
5 x | N (needs -DPIC)
6 x x | Y
7 x x | Y
8 x x x | Y
PPC
static shared -fPIC -mdynamic-no-pic | works
--------------------------------------------------+--------
1 x | Y
2 x x | Y
3 x x | Y
4 x x x | Y
5 x | Y
6 x x | Y
7 x x | *
8 x x x | Y
* -mdynamic-no-pic + shared appears to work for me, but it is heavily recommended against doing. I can't explain why unfortunately.
More information about the ffmpeg-cvslog
mailing list