This is getting to be a pain, specifying a newer libtool, or nm, or ar, or — etc — when a new compiler spits out objects that the default cctools toolchain can’t handle, and yet the configure script, for whatever reason, doesn’t find the current cctools parts by following the PATH. And for builds that use xcodebuild, it’s positively irritating to figure out how to make xcodebuild use a newer compiler instead of the one in the default SDK...
There is functionality to have a toolchain overlay that works in front of Xcode for development at Apple, i believe. I have at times stumbled across certain Xcode environment variables or flags that are designed to prepend a search path onto the Xcode default tool search path. Is anyone familiar enough with this mechanism to describe how it works, and possibly something that might work back to the old systems? My incomplete memory pulls up something like a partial toolchain SDK that goes in front of the real SDK you’re using, and is flagged into the build somehow… Otherwise, all I can come up with is symlinking current cctools into the SDK and /usr/bin in place of the (saved) old ones, which usually, but not always, works out when fixing these whack-a-moles gets too frustrating... Ken
