Re: 64-bit versions of some ports
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)
Thanks for revisiting this. There is a real need to be able to compile, by default, for the native architecture of your machine. There is also a real need to preseve backwards compatibility. A modest proposal (based on posts and discussions old and new) that might please everyone: * Keep the "universal" variant for building architecture-fat binaries (only). * Add a new "fat" variant for building bit-fat binaries (only). * Activate the "fat" variant by default on all library-class ports. * Add an config option to set the default bit-ness ("always 32-bit" or "native") for all builds. Some of it may well be in there already; I haven't been able to locate it in the docs though, e.g. where does "universal_archs" apply...?
I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch", and then made them into parameters for overriding locally if desired.
So is it possible, using the current MacPorts 1.6.0, to build bit-fat/ quad-fat binaries, and if so, how is this accomplished (feel free to bring this onto the users-list)? thx, /Emil
On Feb 11, 2008, at 06:23, Emil Lundberg 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)
Thanks for revisiting this. There is a real need to be able to compile, by default, for the native architecture of your machine. There is also a real need to preseve backwards compatibility. A modest proposal (based on posts and discussions old and new) that might please everyone:
* Keep the "universal" variant for building architecture-fat binaries (only). * Add a new "fat" variant for building bit-fat binaries (only). * Activate the "fat" variant by default on all library-class ports.
What are "library-class ports"? What I mean is: what criteria would you use (what portfile variables, for example) to classify a port as a library-class port?
* Add an config option to set the default bit-ness ("always 32-bit" or "native") for all builds.
Some of it may well be in there already; I haven't been able to locate it in the docs though, e.g. where does "universal_archs" apply...?
I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch", and then made them into parameters for overriding locally if desired.
So is it possible, using the current MacPorts 1.6.0, to build bit- fat/quad-fat binaries, and if so, how is this accomplished (feel free to bring this onto the users-list)?
That comment applied to trunk only. 1.6.0 does not have the universal_archs variable, and has always built only the two 32-bit architectures. MacPorts in trunk has universal_archs, which was for a time set to all 4 architectures, but that didn't work well and then was changed to use only the 2 again. Someone using MacPorts trunk could set universal_archs to a different set of architectures to include in a universal build, but I would not expect any portfile author to have tested with anything other than the default "ppc i386" architecture set.
11 feb 2008 kl. 22.39 skrev Ryan Schmidt:
On Feb 11, 2008, at 06:23, Emil Lundberg 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)
Thanks for revisiting this. There is a real need to be able to compile, by default, for the native architecture of your machine. There is also a real need to preseve backwards compatibility. A modest proposal (based on posts and discussions old and new) that might please everyone:
* Keep the "universal" variant for building architecture-fat binaries (only). * Add a new "fat" variant for building bit-fat binaries (only). * Activate the "fat" variant by default on all library-class ports.
What are "library-class ports"? What I mean is: what criteria would you use (what portfile variables, for example) to classify a port as a library-class port?
A good question indeed; I was hoping you guys could answer that! :-) I think it would need to be determined by the maintainer of the individual port. Many ports are both applications in themselves but also libraries (R, mysql, openssl), so the line is not so clear-cut. My view is that _any_ port that builds shared libraries should (ultimately) compile as bit-fat by default on 64-bit (at least on intel, ppc folks may beg to differ). Perhaps a category ("library", "64bit") could be added to signify this? Or a platform, but that just sounds wrong. But, to get things going, how about simply adding a standard variant "64bit" that, just like "universal", is always available (right?). The daring could then add it to variants.conf, and those who (like myself) take an active interest in 64-bit could try ports out, file bug reports etc. afb had a suggestion on how to handle this in a decently port-neutral I believe. Those on 32-bit machines, etc, would obviously not bother using it unless they wanted to build fat binaries for some reason. Downside is that a variant that might not be tested appears as an option. So how is universal handled? Is it always expected to work if it is available? Can it be disabled for the ports that for some reason don't support it? Can one specify "-universal" for a single port at build time?
* Add an config option to set the default bit-ness ("always 32- bit" or "native") for all builds.
Some of it may well be in there already; I haven't been able to locate it in the docs though, e.g. where does "universal_archs" apply...?
I reverted +universal back to meaning "10.4u SDK for ppc/i386 arch", and then made them into parameters for overriding locally if desired.
So is it possible, using the current MacPorts 1.6.0, to build bit- fat/quad-fat binaries, and if so, how is this accomplished (feel free to bring this onto the users-list)?
That comment applied to trunk only. 1.6.0 does not have the universal_archs variable, and has always built only the two 32-bit architectures. MacPorts in trunk has universal_archs, which was for a time set to all 4 architectures, but that didn't work well and then was changed to use only the 2 again. Someone using MacPorts trunk could set universal_archs to a different set of architectures to include in a universal build, but I would not expect any portfile author to have tested with anything other than the default "ppc i386" architecture set.
Right. I do feel, however, that architecture and bit-ness need to be handled separately. Architechture-fat binaries, I presume, are built to increase usability on several machines (for binary distribution in some form), while bit-fat binaries are commonly built for use on the _same_ machine, e.g. to provide both 32- and 64-bit version of libraries. I can try trunk on a demo setup, using universal_arch="ppc ppc64". How, exactly, do I use this variable? /Emil
participants (2)
-
Emil Lundberg
-
Ryan Schmidt