On 16/06/12 11:11, Peter Dyballa wrote:
> Am 15.06.2012 um 21:19 schrieb Greg A. Woods:
>
>> For example it seems that cpp on OS X does by default look
>> in /usr/local/include for header files, so pkgsrc always invokes cc/gcc
>> and cpp with "-no-cpp-precomp -isystem /usr/include", using the latter
>> option to effectively put /usr/include first, though it doesn't entirely
>> remove /usr/local/include from the search path as I would have expected
>> to be done. (according to the CVS logs and the PR related to the change
>> which added this the reason was to err on the side of being conservative
>> and to not remove /usr/local/include entirely, which is rather stupid
>> and short-sighted in this case, but it solved the original problem from
>> the PR so it was considered sufficient since nobody else at the time
>> seemed to have the time and resources to do further testing).
>
> It's probably more sane to not use another programme, cpp, and instead 'gcc
> -E'. I haven't met, in the last ten or so years, a software that really uses
> cpp. Must have a good reason...
gcc -E invokes the C PreProcessor, commonly referred to as cpp. Whether
this means that /usr/bin/cpp is run or some other binary executable is
irrelevant. The search paths Greg was talking about can be seen from
"gcc -E -v" or from "cpp -v", they are almost the same, and they always
contain /usr/local/include before /usr/include. Just try this with some
simple program, even an empty dummy.c:
gcc -E -v dummy.c
> At least cpp from non-Apple GCC does no relation to /usr/local.
Why do you say this? Try the above with "gcc" replaced by "gcc-fsf-4.7"
and you'll see /usr/local/include before /usr/local just like for
Apple's gcc.
Even if /usr/local/include came after /usr/include (and it always comes
after /sw/include anyway), this would not eliminate the problems we are
having, because they are often caused by something found in
/usr/local/include that does not exist in /{usr,sw}/include. And whereas
the cpp search for include files seems to be rather deterministic and
obeying the order of include directories on the search path, the same
cannot be said about the linker search for libraries, where we have the
same problem. There it often happens that some 3rd party stuff in
/usr/local/lib or in /Library/Frameworks is found and used despite the
correct -L ordering on the linker command line.
The only way to really get rid of interference from 3rd party stuff in
/usr/local (and also /Library/Frameworks) would be to use SDKs
systematically. This would mean a flag
"-isysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
or similar on every compiler line, like Apple does in xcode. Very hard
to impose on every Fink package.
--
Martin
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fink-users mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
