64-bit versions of some ports

[Anders F Björklund]

Ryan Schmidt wrote:

> From the previous discussion, I remember that we (or rather mww) 
> started by changing the +universal variant to build all 4 versions (2 
> architectures each of 32-bit and 64-bit) but this was problematic 
> because many ports failed to build out of the box as 64-bit, and there 
> was no clear upgrade path for those who already had 2-architecture 
> universal variants installed, and it was said that 64-bit versions of 
> most ports don't make sense anyway (aren't faster, or possibly are 
> even slower). But it seems like we want to be able to do this for 
> selected ports.

Most of the ports that failed were using Carbon, or otherwise old...
(old Carbon GUI does not support 64-bit, only Cocoa GUI does that)

I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch",
and then made them into parameters for overriding locally if desired.

> Suppose we say we want to define a new variant called +64bit. Let's 
> figure out what we want that to do. Are we asking for a way to build a 
> 64-bit local-architecture binary instead of a 32-bit 
> local-architecture binary (e.g. x86_64 only)? or in addition to a 
> 32-bit local-architecture binary by installing both into separate 
> paths (e.g. ${prefix}/lib and ${prefix}/lib64 -- I don't think this is 
> the Mac way)? or in addition to a 32-bit local-architecture binary by 
> making a single fat binary (e.g. i386 and x86_64 in one file)? What if 
> the user selects +universal in addition to +64bit? How will we handle 
> that?

I have experimented with adding two new "variants" (or configure 
options):
	+m32
	+m64
These corresponded with the GCC settings with the same name: -m32 and 
-m64.

When doing +m32 it would add -m32 to CFLAGS, and thus make ppc/i386 
binaries.
When saying +m64 it would instead add -m64, and make ppc64/x86_64 
binaries...
The default would be "neither", meaning "go with whatever default GCC 
has",
which would be 32-bit for the Apple version of gcc (Panther-Leopard at 
least)

Or you can use the +universal target, and add all of them to 
universal_archs.
(but this requires that the port supports building universal, at the 
moment)
It probably needs a lot more thought, and needs to be separated from 
configure
so that it can "build twice and merge" for ports not supporting "fat" 
builds.

But for ports using GNU Autotools, the experiments did work out just 
fine. :-)
While I was at it, I also added support for tweaking -march and 
-mtune...

> I saw some commits fly by (by afb) about the universal support in 
> base. Was this something to do with making the universal_archs array 
> configurable? If so, is that user-configurable or port-configurable?

User-configurable. Currently it is run-time, both will be config-time.

One question would be if it would affect the target platform or not ?
i.e. would the platform now be "darwin 9 i386", or "darwin 9 x86_64"
(probably it shouldn't affect the variants at all, but should affect
the binaries created so that they end up as ppc64 and x86_64 instead)

And like you mention, doing multilib on other platforms needs "lib64".
(at least I think it would, as I am not running any 64-bit just yet)

--anders