Is isysroot useful for non-universal?

Ryan Schmidt ryandesign at macports.org
Sat Mar 21 23:43:35 PDT 2009


On Mar 22, 2009, at 00:03, Marcus Calhoun-Lopez wrote:

> Ryan Schmidt <ryandesign at ...> writes:
>
>> On Mar 21, 2009, at 21:34, Marcus Calhoun-Lopez wrote:
>>
>>> It is mentioned in http://trac.macports.org/ticket/17356#comment:6
>>> that universal builds do not suffer from bad .la files because of -
>>> isysroot.
>>
>> That ticket specifically talks about bad .la files installed by some
>> Apple software, relating to X11. We should not need workarounds in
>> MacPorts for these bad files. Apple should distribute software
>> updates to fix the bad files they installed. Further, this specific
>> problem is no longer observed for the majority of users who will
>> presumably not have selected the +system_x11 variant.
>
> Sorry, I was not suggesting a workaround for this particular problem.
> I was making the point that isysroot would have been useful
> when the problem first arose.
>
>>> Perhaps -isysroot could be used to solve other problems as well.
>>
>> What kinds of problems? Do you mean those kinds of problems that
>> arise from the user installing things in /usr/local and MacPorts-
>> installed software inadvertently linking with it?
> ...
>>> It also does not see any changes the user might have made.
>>
>> What kinds of changes are you talking about? Do you mean rogue
>> software installed by the user in system prefixes like / and /usr? I
>> suppose this would help MacPorts avoid linking with additional
>> software the user has installed there. I don't see it helping if the
>> user has replaced existing software.
>
> Yes, I was thinking of unsupported configurations.
> It seems that, with some regularity, reported problems can
> be traced to /usr/local or some other installed software.
> I was thinking that we could reduce the time spent tracking
> down these problems with isysroot and syslibroot.
>
>>
>>> If I understand the behavior, any compiler call with
>>> -isysroot would not see /usr/local/include.
>>
>>  From where do you get that understanding? Is this from the fact that
>> there is no /Developer/SDKs/*/usr/local/include? Any documentation
>> you have on -isysroot would be helpful; I know nothing about it other
>> than the way in which Apple says to use it for building a universal
>> binary.
>
> The documentation on isysroot seems a little sparse.
> According to the cross development documents, isysrtoot is not
> even in the man pages because "this feature is likely to change in  
> the future."
> So my somewhat limited knowledge is from experiments.
> As I understand it, -isysroot /Developer/SDKs/MacOSX10.5.sdk
> treats /Developer/SDKs/MacOSX10.5.sdk/ as / when it comes to includes.
> So it won't find anything in /usr/local/include because
> /Developer/SDKs/MacOSX10.5.sdk/usr/local/include
> does not exist.

Probably what one should do, then, is to dig up some of the tickets  
where software in /usr/local was deemed to be the cause of the  
problem, recreate the issue on a machine, and then change MacPorts to  
use isysroot and/or syslibroot and see if it avoids the problem.



More information about the macports-dev mailing list