Re: plans for 64bit support
---------- Forwarded message ---------- From: Daniel Oberhoff <daniel@danieloberhoff.de> Date: Dec 12, 2007 12:29 PM Subject: Re: plans for 64bit support To: Weissmann Markus <mww@macports.org> [...]
we put some research into this during GSOC this year: It's quite hard to come up with a magic lipo for everything as it is necessary to combine not only binaries (thats the easy part) but also stuff like header files (also easy), heap images of interpreters, scripting language programs, etc. -- which can get practically impossible.
We could enable four-way builds for (probably) all ports that we can build universal right now, but there is currently no way of saying "no ppc64 please" (etc.) in a port (and no tests/experience on what exactly will be necessary).
Hmm, but that would mean I always have to build 4 times and waste lots of space and time I will never ever need (i.e. on my intel mac I will never use ppc binaries). Are ppc+interl universals so important? After all macports is more of a local compile and use thing than about binary distribution, right?
Alternatively maybe have two macports trees, one with 64bit, one with 32bit. Kinda like those lib64 dirs on some linux flavours. Is that possible right now?
You're talking about two collections of port binaries, presumably? Since we don't have any binaries at this point, or any 64-bit builds, anything's possible, of course. Is it wise to have 64-bit- only binaries? I wouldn't have thought so but I really have no idea.
If you mean, is it possible to have 64-bit builds go into lib64 instead of lib, then I would say if that's not the default for the software already, it would be a rather large hassle to fix every portfile to do this, wouldn't you say? And why is this better than a single all-encompassing superuniversal library installed in the normal expected location?
you could always pass a "-arch x86_64" (or "-arch ppc64") to the cflags/cxxflags/.. manually if you desperately need 64 bit support, e.g.: $> port -d install readline configure.cflags="-O2 -arch x86_64" (no idea if that one compiles though)
If you want to make some tests with four-way universal builds, replace each occurrence (there are 3) of "-arch i386 -arch ppc" in / opt/local/share/macports/Tcl/port1.0/portconfigure.tcl with "-arch i386 -arch x86_64 -arch ppc -arch ppc64". We are of course interested in your results... ;)
Hmm, no, this went down the wrong path. Let me clarify: Someone before said that on Leopard macports would automatically build 64 bit binaries. Now I was wondering if a) I could prevent this (i.e. have it build 32bit as before) b) If I could have two completely independent macports repos on my disk, one built 32bit and one 64bit. This would be ideal since most everyday stuff is 32bit, and only some libs and stuiff are needed for 64. I would go as far as saying this latter option would be the best solution (less hassle than doing universal builds and better controllable), for the 32/64 bit versions I would really like this supported in macports properly, and not have to fiddle with build flags... I would like a repo-constant switch for this. I.e. some repo (I refer to repo as a local macports install tree, i.e. what is usually under /opt/local) would be set up as 64bit and always be 64bit from there on (i.e. update, install and all when on this repo do 64bit builds). And another would be 32bit. One could do the same for ppc. I think real universal binaries are only ever needed for distribution, and then one can always go and lipo things by hand. So is this kind of repo-based architecture selection possible. And the installation of multiple macports repos? If not I would even help make it possible if someone gets me started :).
For octave you're out of luck though as it is build with the vanilla gcc 4.2 which cannot produce universal binaries. Perhaps you can test the Apple gcc 4.2 beta preview for octave to achieve this (if you're on 10.5) -- though the Fortran part may be a problem here as octave seems to use it (the Apple compilers don't do Fortan while the vanilla ones cannot create universal binaries).
That's ok. I use the regular 4.0 now, building octave from cvs. Octave building on osx is not very hard anymore, they seem to have a grip on it now. I would just like macports to handle dependencies :). Best Daniel
On 12.12.2007, at 12:31, Daniel Oberhoff wrote:
---------- Forwarded message ---------- From: Daniel Oberhoff <daniel@danieloberhoff.de> Date: Dec 12, 2007 12:29 PM Subject: Re: plans for 64bit support To: Weissmann Markus <mww@macports.org>
[...]
we put some research into this during GSOC this year: It's quite hard to come up with a magic lipo for everything as it is necessary to combine not only binaries (thats the easy part) but also stuff like header files (also easy), heap images of interpreters, scripting language programs, etc. -- which can get practically impossible.
We could enable four-way builds for (probably) all ports that we can build universal right now, but there is currently no way of saying "no ppc64 please" (etc.) in a port (and no tests/experience on what exactly will be necessary).
Hmm, but that would mean I always have to build 4 times and waste lots of space and time I will never ever need (i.e. on my intel mac I will never use ppc binaries). Are ppc+interl universals so important? After all macports is more of a local compile and use thing than about binary distribution, right?
Well, our ultimate goal here would be to have these 4-way universal builds as packages... but don't hold your breath for this to happen: There is a lot of work to be done for this. Regarding the space and time issue: Yes, building universal will take roughly 4 times as long, but not take 4 times the space: The most space is normally consumed by data files like documentation, pictures, icons, etc.
Alternatively maybe have two macports trees, one with 64bit, one with 32bit. Kinda like those lib64 dirs on some linux flavours. Is that possible right now?
You're talking about two collections of port binaries, presumably? Since we don't have any binaries at this point, or any 64-bit builds, anything's possible, of course. Is it wise to have 64-bit- only binaries? I wouldn't have thought so but I really have no idea.
If you mean, is it possible to have 64-bit builds go into lib64 instead of lib, then I would say if that's not the default for the software already, it would be a rather large hassle to fix every portfile to do this, wouldn't you say? And why is this better than a single all-encompassing superuniversal library installed in the normal expected location?
you could always pass a "-arch x86_64" (or "-arch ppc64") to the cflags/cxxflags/.. manually if you desperately need 64 bit support, e.g.: $> port -d install readline configure.cflags="-O2 -arch x86_64" (no idea if that one compiles though)
If you want to make some tests with four-way universal builds, replace each occurrence (there are 3) of "-arch i386 -arch ppc" in / opt/local/share/macports/Tcl/port1.0/portconfigure.tcl with "-arch i386 -arch x86_64 -arch ppc -arch ppc64". We are of course interested in your results... ;)
Hmm, no, this went down the wrong path. Let me clarify: Someone before said that on Leopard macports would automatically build 64 bit binaries. Now I was wondering if
a) I could prevent this (i.e. have it build 32bit as before) b) If I could have two completely independent macports repos on my disk, one built 32bit and one 64bit. This would be ideal since most everyday stuff is 32bit, and only some libs and stuiff are needed for 64. I would go as far as saying this latter option would be the best solution (less hassle than doing universal builds and better controllable),
for the 32/64 bit versions I would really like this supported in macports properly, and not have to fiddle with build flags... I would like a repo-constant switch for this. I.e. some repo (I refer to repo as a local macports install tree, i.e. what is usually under /opt/local) would be set up as 64bit and always be 64bit from there on (i.e. update, install and all when on this repo do 64bit builds). And another would be 32bit. One could do the same for ppc. I think real universal binaries are only ever needed for distribution, and then one can always go and lipo things by hand.
So is this kind of repo-based architecture selection possible. And the installation of multiple macports repos? If not I would even help make it possible if someone gets me started :).
By default the Apple compilers will produce 32 bit binaries, so if you don't do anything, you'll end up with 32 bit ppc or i386 binaries. We currently don't have a switch to enable 64 bit binaries, so no: "just" installing MacPorts a 2nd time isn't getting you anywhere near there. I'd recommend (for now) to hack the portconfigure.tcl [1] file and replace "-arch i386 -arch ppc" with "-arch i386 -arch x86_64", then build the stuff you need with "+universal". For more awesomeness to happen sooner, I'd advice to start hacking port(1) with us... ;) Regards, -Markus --- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/
a) I could prevent this (i.e. have it build 32bit as before) b) If I could have two completely independent macports repos on my disk, one built 32bit and one 64bit. This would be ideal since most everyday stuff is 32bit, and only some libs and stuiff are needed for 64. I would go as far as saying this latter option would be the best solution (less hassle than doing universal builds and better controllable),
for the 32/64 bit versions I would really like this supported in macports properly, and not have to fiddle with build flags... I would like a repo-constant switch for this. I.e. some repo (I refer to repo as a local macports install tree, i.e. what is usually under /opt/local) would be set up as 64bit and always be 64bit from there on (i.e. update, install and all when on this repo do 64bit builds). And another would be 32bit. One could do the same for ppc. I think real universal binaries are only ever needed for distribution, and then one can always go and lipo things by hand.
So is this kind of repo-based architecture selection possible. And the installation of multiple macports repos? If not I would even help make it possible if someone gets me started :).
By default the Apple compilers will produce 32 bit binaries, so if you don't do anything, you'll end up with 32 bit ppc or i386 binaries. We currently don't have a switch to enable 64 bit binaries, so no: "just" installing MacPorts a 2nd time isn't getting you anywhere near there. I'd recommend (for now) to hack the portconfigure.tcl [1] file and replace "-arch i386 -arch ppc" with "-arch i386 -arch x86_64", then build the stuff you need with "+universal". For more awesomeness to happen sooner, I'd advice to start hacking port(1) with us... ;)
Hehe :). Well, I would first like to know if and how I can install a second macports tree. As I would prefer that over building inversals. Once I get there I will see how I can force one tree to build 64bit and report on what I come up with. But I might also play with that universal hack...if it is that easy, why can't it be automated? Daniel
On Dec 12, 2007, at 06:28, Daniel Oberhoff wrote:
a) I could prevent this (i.e. have it build 32bit as before) b) If I could have two completely independent macports repos on my disk, one built 32bit and one 64bit. This would be ideal since most everyday stuff is 32bit, and only some libs and stuiff are needed for 64. I would go as far as saying this latter option would be the best solution (less hassle than doing universal builds and better controllable),
for the 32/64 bit versions I would really like this supported in macports properly, and not have to fiddle with build flags... I would like a repo-constant switch for this. I.e. some repo (I refer to repo as a local macports install tree, i.e. what is usually under /opt/local) would be set up as 64bit and always be 64bit from there on (i.e. update, install and all when on this repo do 64bit builds). And another would be 32bit. One could do the same for ppc. I think real universal binaries are only ever needed for distribution, and then one can always go and lipo things by hand.
So is this kind of repo-based architecture selection possible. And the installation of multiple macports repos? If not I would even help make it possible if someone gets me started :).
By default the Apple compilers will produce 32 bit binaries, so if you don't do anything, you'll end up with 32 bit ppc or i386 binaries. We currently don't have a switch to enable 64 bit binaries, so no: "just" installing MacPorts a 2nd time isn't getting you anywhere near there. I'd recommend (for now) to hack the portconfigure.tcl [1] file and replace "-arch i386 -arch ppc" with "-arch i386 -arch x86_64", then build the stuff you need with "+universal". For more awesomeness to happen sooner, I'd advice to start hacking port(1) with us... ;)
Hehe :). Well, I would first like to know if and how I can install a second macports tree.
Documented: http://guide.macports.org/#installing.source.multiple
As I would prefer that over building inversals. Once I get there I will see how I can force one tree to build 64bit and report on what I come up with. But I might also play with that universal hack...if it is that easy, why can't it be automated?
Are you asking: why haven't we dealt with 4-way universal binaries or any kind of 64-bit support before? I don't think anybody's asked for it before.
On Dec 12, 2007 1:43 PM, Ryan Schmidt <ryandesign@macports.org> wrote:
On Dec 12, 2007, at 06:28, Daniel Oberhoff wrote:
a) I could prevent this (i.e. have it build 32bit as before) b) If I could have two completely independent macports repos on my disk, one built 32bit and one 64bit. This would be ideal since most everyday stuff is 32bit, and only some libs and stuiff are needed for 64. I would go as far as saying this latter option would be the best solution (less hassle than doing universal builds and better controllable),
for the 32/64 bit versions I would really like this supported in macports properly, and not have to fiddle with build flags... I would like a repo-constant switch for this. I.e. some repo (I refer to repo as a local macports install tree, i.e. what is usually under /opt/local) would be set up as 64bit and always be 64bit from there on (i.e. update, install and all when on this repo do 64bit builds). And another would be 32bit. One could do the same for ppc. I think real universal binaries are only ever needed for distribution, and then one can always go and lipo things by hand.
So is this kind of repo-based architecture selection possible. And the installation of multiple macports repos? If not I would even help make it possible if someone gets me started :).
By default the Apple compilers will produce 32 bit binaries, so if you don't do anything, you'll end up with 32 bit ppc or i386 binaries. We currently don't have a switch to enable 64 bit binaries, so no: "just" installing MacPorts a 2nd time isn't getting you anywhere near there. I'd recommend (for now) to hack the portconfigure.tcl [1] file and replace "-arch i386 -arch ppc" with "-arch i386 -arch x86_64", then build the stuff you need with "+universal". For more awesomeness to happen sooner, I'd advice to start hacking port(1) with us... ;)
Hehe :). Well, I would first like to know if and how I can install a second macports tree.
Documented:
Thanks, rtfm I guess :).
As I would prefer that over building inversals. Once I get there I will see how I can force one tree to build 64bit and report on what I come up with. But I might also play with that universal hack...if it is that easy, why can't it be automated?
Are you asking: why haven't we dealt with 4-way universal binaries or any kind of 64-bit support before? I don't think anybody's asked for it before.
Sure, Leopard is quite new and all. Hmm, but I remember someone said its really complicated...anyhow, I will probably try both ways sometime this week and report on my findings. Best Daniel
participants (3)
-
Daniel Oberhoff
-
Ryan Schmidt
-
Weissmann Markus