This discussion belongs on the mailing list, not in my private mailbox. Please use Reply To All when replying. On Dec 11, 2007, at 04:30, Keith J. Schultz wrote:
Am 11.12.2007 um 09:50 schrieb 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.
Hi Everybody,
Why would someone with a Intel or PowerPC want to build a universal for a port. I mean it is build on one machine and is used on one machine. I can understand the variants for Intel and PowerPC as well as the need for 32 or 64 bit variants, but universal no way.
Yes, a port author will want to test and build the different variants, but why universal. I mean ports does not need unversal variants on the pure unix side. Cocoa Apps is a different matter, but since they are build on the host machine we could do with out it. So we have: 1) Intel + 64 2) Intel + 32 3) PowerPC + 64 (G5 only) 4) PowerPC + 32
I believe that which version to build can be guess by looking at the CPU. Should not autoconfig handle that?
regards Keith.
I don't think now is the time to second-guess MacPorts's universal support, which has been around since r22313 10 months ago and is being improved on a port by port basis as problems are discovered. MacPorts's universal support is explained in the first item of the FAQ: http://trac.macports.org/projects/macports/wiki/FAQ#IsMacPortsUniversal True, most users do not need universal ports. But some do. Some install MacPorts on an external hard drive that they might connect to either a PowerPC- or an Intel-based Mac. Or some users may install MacPorts on their current PowerPC Mac, then later use Migration Assistant to migrate the content of their hard drive to a newly- bought Intel-based Mac. Users who have installed +universal versions of all ports can continue unhindered, while those who did not will have to blow away their MacPorts installation, reinstall MacPorts and re-build all their ports. A goal of MacPorts is to eventually distribute binaries of ports, rather than make everyone compile things themselves. It would be inconvenient to have to maintain separate PowerPC and Intel binaries, hence the desire to have universal binaries so we can have just a single binary download for each port. If and when that ever happens. Therefore, we certainly don't want to now increase the number of binary ways the software can be built, so we don't want separate ways to build fat Intel or fat PowerPC binaries. Rather, I would suggest, as I suggested before, that we should have the default, which builds for the local host architecture only, which most users today will use, and we should have +universal, as we do now, but which can be extended to support all 4 binary types that one might conceivably want, if indeed 64-bit binaries are useful to have. As far as I know, autoconf was conceived without having considered multiple-architecture binaries, so I don't know that it's going to be any help in building fat or universal binaries.
Hi Everybody, On 11.12.2007, at 12:23, Ryan Schmidt wrote: [...] I totally agree with Ryan's argumentation on avoiding to many distinct lines of binaries and would suggest the people that are interested in 64 bit support or willing to help, extend +universal to include 32 bit and 64 bit binaries for PPC and Intel, all at once. [...]
if indeed 64-bit binaries are useful to have
Well, I have been running numerical simulations on 64 bit machines/ OSs already for more than ten years (starting with DEC AlphaStations at the time) because they run considerably faster on the 64 bit architecture or wouldn't run on 32 bit at ll (for memory constraints). I have not yet done that on Mac OS X but currently use 64-bit variants of Linux, but I do see the use and actual need for 64 bit support on Mac OS X. Especially for some of the nice numerics tools in MacPorts! Therefore, I think we should strongly consider to support 64 bit in some way. See above for my standpoint on Ryan's email. As a side-node: I wonder when we finally get rid of 32 bit and, moreover, when we get 128 bit floating point hardware back (Mr Cray, are you still around;) Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen- Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll
Hi All, Am 11.12.2007 um 12:54 schrieb Jochen Küpper:
Hi Everybody,
On 11.12.2007, at 12:23, Ryan Schmidt wrote:
[...]
I totally agree with Ryan's argumentation on avoiding to many distinct lines of binaries and would suggest the people that are interested in 64 bit support or willing to help, extend +universal to include 32 bit and 64 bit binaries for PPC and Intel, all at once.
[...]
if indeed 64-bit binaries are useful to have
Well, I have been running numerical simulations on 64 bit machines/ OSs already for more than ten years (starting with DEC AlphaStations at the time) because they run considerably faster on the 64 bit architecture or wouldn't run on 32 bit at ll (for memory constraints).
I have not yet done that on Mac OS X but currently use 64-bit variants of Linux, but I do see the use and actual need for 64 bit support on Mac OS X. Especially for some of the nice numerics tools in MacPorts!
Therefore, I think we should strongly consider to support 64 bit in some way. See above for my standpoint on Ryan's email. I would agree that we need 64-bit support as many work cutting edge and 64-bit is needed.
As a side-node: I wonder when we finally get rid of 32 bit and, moreover, when we get 128 bit floating point hardware back (Mr Cray, are you still around;)
Well, lets see we had the 6502 in the 80s, a little later 16 bit, the 90s had 16 and 32 bit, 64 is now becomming the standard so I would guess we will 128-bit in about another 15-20 years. regards Keith.
On 12.12.2007, at 10:20, Keith J. Schultz wrote:
Am 11.12.2007 um 12:54 schrieb Jochen Küpper:
As a side-node: I wonder when we finally get rid of 32 bit and, moreover, when we get 128 bit floating point hardware back (Mr Cray, are you still around;)
Well, lets see we had the 6502 in the 80s, a little later 16 bit, the 90s had 16 and 32 bit, 64 is now becomming the standard so I would guess we will 128-bit in about another 15-20 years.
On the other hand, 64 bit was introduced in supercomputers in the 1960s and in RISC workstations around 1990 (for example, the Alpha 21064 (EV4) was introduced in 1992). Already in the 1970s IBM System/370 had 128-bit floating point arithmetic... Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen- Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll
participants (3)
-
Jochen Küpper
-
Keith J. Schultz
-
Ryan Schmidt