plans for 64bit support

[Ryan Schmidt]

On Dec 11, 2007, at 02:35, Daniel Oberhoff wrote:

> Am 10.12.2007 um 01:33 schrieb Ryan Schmidt:
>
>> On Dec 9, 2007, at 14:43, Daniel Oberhoff wrote:
>>
>>> Now that Leopard is out and already at 10.5.1 will macports be  
>>> supporting 64bit libraries? It's just I need 64bit in my octave  
>>> installation. I pull my octave from octave.org's cvs, but it  
>>> needs quite a lot of support libraries. From what I gather it  
>>> should be possible on Leopard to build fat libraries, i.e. ones  
>>> that contain 64 and 32 bit code (i think it works using -arch  
>>> x84_64 -arch i686 as gcc flags). Or will this be left to the  
>>> separate ports?
>>
>> MacPorts is supposed to build libraries for whatever system it's  
>> running on. So I would have thought that if you're on a 64-bit  
>> Intel system, it should build 64-bit Intel libraries. Is it  
>> building 32-bit Intel libraries for you?
>>
>> We have the +universal variant for building 2-way (32-bit, Intel  
>> and PowerPC) universal binaries. We are still in the process of  
>> getting this to work with many of the ports. It could be changed  
>> to build 4-way (32-bit and 64-bit, Intel and PowerPC) universal  
>> binaries. This should be possible on Tiger too, as far as I know.  
>> It won't fix any ports that are having trouble building 2-way  
>> universal binaries. Not sure if it would mess up any ports that  
>> are already working. Are all the ports that you need already  
>> working as 2-way universal binaries?
>>
>> I haven't heard anyone suggest building libraries that contain 32- 
>> bit and 64-bit code for just one processor family before (in  
>> relation to MacPorts). It would of course be possible, but I think  
>> it would make most sense to continue along our current path:  
>> software should be default install for the architecture you're on,  
>> and if you need multiple architectures, then you need the  
>> +universal variant.
>>
>> It has been said before that maybe 64-bit binaries aren't all that  
>> helpful, but the Ars Technica review of Leopard explains that  
>> while 64-bit binaries aren't that helpful on the PowerPC  
>> architecture, they really are quite good for secondary reasons on  
>> the Intel architecture. The 32-bit Intel architecture has often  
>> been called inferior to the 32-bit PowerPC architecture, but the  
>> 64-bit Intel architecture seems to fix many of the issues. Also,  
>> maybe Leopard being a full 64-bit system makes 64-bit binaries  
>> more relevant.
>>
>> Perhaps we could do 4-way universal binaries only when MacPorts is  
>> running on Leopard.... but that might be a bad idea, since only  
>> people running Leopard could  then develop and test this.
>>
>> We could introduce a new automatic variant... +universal4?  
>> +universal64? People could test with this new variant and if any  
>> problems are encountered it would not prevent anyone from using  
>> the existing 2-way 32-bit +universal variant. I'm wary of this  
>> though... I wouldn't want, say, "universal64" directives to start  
>> appearing in portfiles, if we want to eventually fold +universal64  
>> into +universal.
>>
>> Just some thoughts off the top of my head.
>
> Hmm, ok. That makes sense, since I upgraded with an installed  
> macports base. I suppose I should really reinstall all then, since  
> otherwise I will end up with a crazy mix?

Yes, if you're moving from one architecture to another (G4->G5, PPC- 
 >Intel, 32-bit->64-bit, etc.) you should really throw away your old  
MacPorts (saving any conf files or databases or other data) and  
rebuild all your ports.

> Though, per default on Leopard compilation seems to be 32 bit. When  
> you just compile something without further options pointer size is  
> 32bit. Only when you specify -arch x86_64 or -m64 do you get 64bit.

Ah, I see. I didn't know. I haven't had a 64-bit machine.

> So it would really make sense to have both (but not ppc). So I  
> would vote for an autamatic variant to get intel only 32/64bit.

So by default we build 32-bit binaries for the host architecture. And  
we have a +universal variant for building 32-bit binaries for both  
architectures. You want an additional variant for building fat 32-bit  
and 64-bit Intel binaries. Do we then also need a separate variant  
for building fat 32-bit and 64-bit PowerPC binaries? And what about a  
fat universal variant with all 4 options? This proliferation of  
variants is what I want to avoid. Most users will not need it and it  
will confuse some of them. It's much extra work for some portfile  
authors, because some software (rather a lot, actually) does not  
build successful universal binaries using the simple tricks, and much  
more work is required to build universal. See for example the openssl  
port (which, to build universal, you'll have to back-date to version  
0.9.8e because of bug #12911) which goes through crazy hoops to build  
first for one architecture, then the other, then lipo them together.  
Similar (though perhaps not identical) hoops would have to be gone  
through for fat binaries or 4-way binaries. Well, that is until  
MacPorts base grows some universal-build helpers. (I still really  
think MacPorts base should have an easy way to build a port multiple  
times, once for each architecture, and lipo it together,  
automatically, selected with just a single line in the portfile).


Why, by the way, do you need 64-bit octave? Just curious.