The ability for MacPorts to build 64-bit versions of ports was discussed a little while ago, but I don't think there was any resolution. Let's try again. Paulo Moura wrote to me because users of his swi-prolog port have requested this (requires dependencies gmp and readline to be 64-bit too): On Jan 30, 2008, at 05:30, Paulo Moura wrote:
Some time ago, I posted to the mailing list a message about 64 bits variants but received no reply. Maybe you're able to provide me some feedback on this issue. I would like to add 64 bits variants to some port such as "readline" and "gmp". Is my understanding (please correct me if I'm wrong) that 64 bits and 32 bits versions of the same library co-exist peacefully. The reason I'm asking is that some SWI-Prolog users are asking for a 64 bits variant. In order to provide this 64 bits variant I need first to have 64 bits variants in-place for all the libraries SWI-Prolog depend on.
And Randy Melder requested this for my mysql5 port (probably requires 64-bit openssl and zlib): On Jan 28, 2008, at 12:35, Randy Melder wrote:
Is this a 64bit compile, or 32? I seems the 32bit compiles have problems with allocating memory above 2GB.
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. 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 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? The above is really just babbling to demonstrate that I don't know what to do about this problem. Maybe someone else can be smarter for me and figure it out.
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
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)
On second thought, we don't need any /opt/local/lib/{lib32,lib64} or multilib on other platforms - just one native "lib" directory. Just because the system has /usr/lib/lib32 and /usr/lib/lib64 for compatibility, doesn't mean one has to compile using it... Then again, I said the same thing about Universal Binaries too. So maybe MP does "need" multilib, like it "needed" +universal ? But compiling 64-bit binaries on a 64-bit system, _that_ is at least a often required feature and thus it should be supported. --anders PS. http://www.redhat.com/magazine/009jul05/features/multilib/ (on Darwin this is all handled by using the fat binaries)
participants (2)
-
Anders F Björklund
-
Ryan Schmidt