[FFmpeg-cvslog] r20497 - trunk/configure

[Alexander Strange]

On Mar 29, 2010, at 2:11 PM, M?ns Rullg?rd wrote:

> Alexander Strange <astrange at ithinksw.com> writes:
> 
>> On Nov 10, 2009, at 7:57 AM, reimar wrote:
>> 
>>> Author: reimar
>>> Date: Tue Nov 10 13:57:28 2009
>>> New Revision: 20497
>>> 
>>> Log:
>>> Check if PIC is somehow already enabled (e.g. a compiler that
>>> enables it by default).  This in particular ensures that -DPIC is
>>> set appropriately for YASM, which avoids linking failures on x86_64
>>> for compilers that have PIE enabled by default (e.g. hardened
>>> Gentoo).  It also makes the macho64 special-case hack adding -DPIC
>>> to YASMFLAGS obsolete.
>> 
>> This broke adding -mdynamic-no-pic on Darwin again.
>> 
>> Is it safe to move the check after the OS section?
>> 
>> 
>> Index: configure
>> ===================================================================
>> --- configure	(revision 20538)
>> +++ configure	(working copy)
>> @@ -1913,7 +1913,6 @@
>> 
>> enable $arch $subarch
>> enabled spic && enable pic
>> -check_cpp_condition stdlib.h "defined(__PIC__) || defined(__pic__) || defined(PIC)" && enable pic
>> 
>> # OS specific
>> case $target_os in
>> @@ -2081,6 +2080,8 @@
>>         ;;
>> esac
>> 
>> +check_cpp_condition stdlib.h "defined(__PIC__) || defined(__pic__) || defined(PIC)" && enable pic
>> +
>> set_default $PATHS_LIST
>> 
>> add_extralibs $osextralibs
> 
> I guess this is OK.  I can't wrap my head around the pic madness on
> osx, but I'll trust you if you say it works.  I don't see anything
> else in the OS section depending on it.

It's quite confusing and unnecessary, I wish they'd fixed it when it first came out.
At least x86-64 doesn't have this problem.

Applied.