XCode 4.3

Aljaž Srebrnič a2piratesoft at gmail.com
Fri Feb 17 05:26:45 PST 2012


By the way, I noted that there's a new handy tool included (at least I think it is new): xcrun
and so, the clang bundled with Xcode can be obtained via $(xcrun -find clang)

Aljaž Srebrnič
-- --
My public key:  http://bit.ly/g5pw_pubkey

On 17/feb/2012, at 14:15, Eric Cronin wrote:

> On Feb 17, 2012, at 1:56 AM, Joshua Root wrote:
>> On 2012-2-17 15:38 , Eric Cronin wrote:
>>> The main problem I ran in to is that a number of our ports cache the compiler they were built with internally (libtool, python, apr), and then a number of other ports interrogate those first set of ports to get the paths of tools to use, resulting in attempts to compile using /Developer/.../llvm-g*-4.2, which no longer exists.  This is probably a bug with the dependent ports from a MacPorts angle, since we want the compiler the Portfile/base specifies used, not what 'apr-1-config --cc' returns.  Force reinstalling the ports caching paths to the toolchain allowed the remaining ports to be built.  Some variant of the migration upgrade steps is probably required to make sure nothing has /Developer paths stored away…
>> 
>> This isn't a problem with libtool at least since the build systems still
>> obey CC in the configure environment. You do get problems if they then
>> neglect to use the appropriate --tag argument when invoking libtool, but
>> that can and should be patched.
>> 
>> - Josh
>> 
> 
> audiofile would not update correctly until I rebuilt libtool, at which point it did.  I don't know if audiofile or libtool is to blame there, but libtool was where it was learning /Developer from…
> 
> Thanks,
> Eric
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev



More information about the macports-dev mailing list