a2piratesoft at gmail.com
Wed Feb 1 15:05:10 PST 2012
On 01/feb/2012, at 23:38, Ryan Schmidt wrote:
> On Feb 1, 2012, at 10:58, Aljaž Srebrnič wrote:
>> No, no PortGroup is used, but compiler.cpath solves the issue!
>> It is strangely undocumented, though… :/
> Yup. It was never clear to me why we added CPATH and LIBRARY_PATH to MacPorts base, since the existing CPPFLAGS and LDFLAGS we set in the configure phase should have the same effect for properly-behaved ports, and improperly-behaved ports should be fixed. Now that Xcode 4.2 users are using clang, and clang does not use CPATH or LIBRARY_PATH , it may truly be time to admit that CPATH and LIBRARY_PATH are not helping us (they are merely causing those of us who don't use clang to commit ports that may not work for users using clang), and remove them.
> Then again, this may be fixed in future versions of clang. CPATH support was already added ; adding LIBRARY_PATH support  has not been discussed yet however.
> Out of curiosity, why are you needing to remove CPATH? What problem is having it set causing you?
I was doing some testing on msp430-* ports and when i had libunwind-headers installed (which provided /opt/local/include/unwind.h) the build phase for msp430-gcc* failed because it was including the unwind.h in /opt/local/include/unwind.h and not the one in the build directory…
Note: the install failed in the libgcc build phase (when clang is _not_ used)
>  http://lists.macosforge.org/pipermail/macports-dev/2011-August/015543.html
>  http://llvm.org/bugs/show_bug.cgi?id=8971
>  http://llvm.org/bugs/show_bug.cgi?id=10296
My public key: http://bit.ly/g5pw_pubkey
More information about the macports-users