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

[Ronald Oussoren]

On 5 May, 2011, at 12:19, David Brooks wrote:

> 
> 
> 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".

Oops...  I don't understand why I didn't notice this myself.  I've filed issue #9388597 for this in Apple's tracker.   If you have a developer account you can file an issue about this as well, the amount of developers that report the same bug affects how soon Apple will actually address the issue (if ever). 

Ronald


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20110505/88398d92/attachment.bin>