[Pythonmac-SIG] Extension module compile fail, due to isysroot param pointing to sdk without certain headers. Any tips?

[David Brooks]

On 5/05/11 6:06 PM, Ronald Oussoren wrote:
> On 3 May, 2011, at 20:28, Irmen de Jong wrote:
>>
>>> I haven't looked into the problem you have with automaticly picking up dependencies
>>> in /usr/local,  AFAIK that should just work the same as without -isysroot.
>> charon:~ irmen$ cat /usr/local/include/irmen.h
>> #define FOO 1
>>
>> charon:~ irmen$ cat test.c
>> #include<irmen.h>
>> int main(void)
>> {
>> return 0;
>> }
>>
>> charon:~ irmen$ gcc test.c
>> charon:~ irmen$
>> charon:~ irmen$ gcc -isysroot /Developer/SDKs/MacOSX10.4u.sdk test.c
>> test.c:1:19: error: irmen.h: No such file or directory
>>
>>
>> According to what gcc prints when compiling with -v, the -isysroot replaces
>> /usr/local/include include-path (and some others). So it's expected that it now fails to
>> compile, right? I can get it to compile again when I explicitly add /usr/local/include
>> to the include path once more:
>>
>> $ MACOSX_DEPLOYMENT_TARGET=10.4 gcc -I/usr/local/include -isysroot
>> /Developer/SDKs/MacOSX10.4u.sdk test.c
>>
>> I guess the situation is the same with libs living in /usr/local/lib.
>>
>> I'm not entirely sure though if the above is what you were talking about Ronald?
> -isysroot /FOO adds "/FOO" to the front of items on the default search path for the compiler,
> that is instead of looking in "/usr/include" the compiler will look in "/FOO/usr/include".
>
> For you example this means that the compiler will look in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/include
> for "irmen.h". That should work because "/usr/local" in the SDK is a symlink to the actual system-wide
> "/usr/local" directory:
>
> $ ls -l /Developer/SDKs/MacOSX10.4u.sdk/usr/local
> total 8
> lrwxr-xr-x  1 root  wheel  14 Mar 24 09:10 lib ->  /usr/local/lib
>
> This is on a 10.6 system with Xcode 3, but I'm pretty sure that the compiler worked the same in earlier
> releases.  Have you changed files in the SDK?
>
> BTW. The reason "-I/usr/local/include" fixes your prolbem is that the location is then added
> as a user-supplied item on the search path and those aren't resolved relative to the SDK root.
>
> Ronald
>

Aha, the problem is because "./usr/local" in the SDK **does not** 
symlink to the system "/usr/local". Instead "./usr/local/lib" is 
symlinked to "/usr/local/lib, and there is no corresponding symlink to 
"/usr/local/include".


Dave