On Jan 22, 2010, at 18:57, Jim Busser wrote:

> On 2010-01-22, at 4:20 PM, Scott Haneda wrote:
> 
>> In macports.conf I see:
>>   # CPU architecture to compile for. Defaults to i386 or ppc on Mac OS X 10.5
>>   # and earlier, depending on the CPU type detected at runtime. On Mac OS X 
>> 10.6
>>   # the default is x86_64 if the CPU supports it, i386 otherwise.
>>   #build_arch                     i386
> 
> The build_arch appears commented-out to allow for what are (contended to be) 
> usually-suitable defaults.

We make no specific contention that the MacPorts default build_arch is 
suitable. We merely contend that it matches the behavior of the gcc that Apple 
ships in Xcode.


> I too use a MacBook and account of the following line for me returns EFI32
> 
>       ioreg -l -p IODeviceTree | awk -F'"' '/firmware-abi/{print $4}'
> 
> I am wondering if it means that --- despite that I am running 10.6 -- my 
> ports will only build i386 anyway so I wonder whether the admonitions to 
> build universal (under Snow Leopard) as x86_64 i386 are, for me and people 
> running similar machines, simply a waste of time. Unless what it is, is that 
> Snow Leopard through "Apple Magic" is able to run 64-bit applications despite 
> that the processor is unable to run a 32-bit kernel and whether that is the 
> reason it still makes sense to compile x86_64 under a limited processor. But 
> the x86_64 will be insufficient for some depedent ports if they had been 
> either unable to also be compiled under 64-bit, or happened not to be.

Your EFI and whether your Mac can use a 64-bit kernel is irrelevant. What 
matters is whether your processor can run 64-bit code. This can be determined 
by running this command:

sysctl hw.cpu64bit_capable

Or, by simply noting whether you have a Core or Core 2 processor. Core is 
32-bit, Core 2 and every other Intel processor used in a Mac is 64-bit.


>> I am still at a loss as to what is generating the "Variants: darwin_10, 
>> universal" line.
> 
> Evidently a portfile's "platform(s)" even despite absence from the portfile's 
> "variants" clauses get treated in the MacPorts web site listing (I am not 
> sure about the guide) as a "variant" despite that if you would specify in the 
> port command line, you get chastised by the console as well as on-list by the 
> non-newbies :-)

I didn't understand the point of your paragraph. But anyway "platforms" and 
"variants" are treated similarly by MacPorts. The difference is that platforms 
are selected automatically by MacPorts and variants are selected manually by 
the user.


>>   # machine architectures
>>   universal_archs         x86_64 i386
> 
> Based on my own attempts to learn mainly from Ryan's answers, :-)
> 
> - I think universal_archs is not enough by itself... it is accessed on demand 
> when explicitly asked for in the command line whether by +universal or
> 
>       sudo port upgrade --enforce-variants installed +universal
> 
> or (in variants.conf, to make it automatic when possible) add
> 
>       +universal
> 
> except when circumvented by a portfile usage of
>       "use_configure no" – see macports ticket 12170
> or
>       "universal_variant no"
> 
> and (I think) extraneous to those portgroups (e.g. cmake, xcode) which 
> provide their own universal variants.

The universal_archs setting is used by ports when they build universal. 
(Conversely, the build_arch setting is used by ports when they do not build 
universal.) You tell a port to build universal by requesting the +universal 
variant by any of the available means.

_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Reply via email to