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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Reply via email to