plans for 64bit support

[Daniel Oberhoff]

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? 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. 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.

Daniel

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.
>