2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog)
On Jan 16, 2008, at 06:55, afb@macports.org wrote:
Revision: 32999 http://trac.macosforge.org/projects/macports/changeset/32999 Author: afb@macports.org Date: 2008-01-16 04:55:44 -0800 (Wed, 16 Jan 2008)
Log Message: ----------- update changelog for r32194 and r32724
Modified Paths: -------------- trunk/base/ChangeLog
Modified: trunk/base/ChangeLog =================================================================== --- trunk/base/ChangeLog 2008-01-16 11:01:26 UTC (rev 32998) +++ trunk/base/ChangeLog 2008-01-16 12:55:44 UTC (rev 32999) @@ -6,6 +6,10 @@
Unreleased:
[snip]
+ - Enable 64 bit environment, ppc64 x86_64, for all +universal builds (mww in r32194).
May I change this so that we only build 32-bit versions again, please? I've already encountered ports that built fine as 32-bit universals that fail as 64-bit universals. Also, we still haven't thought of a solution for all the users who already have 32-bit +universal ports installed. What happens when they upgrade to a version of MacPorts that includes this change and continue building +universal ports? Everything goes to Hell, that's what happens, because the new ports want to build 4 architectures but the existing dependencies are only built with 2 architectures. If nobody offers a clear objection to this in 72 hours I'll change it to just the two 32-bit architectures again.
+ - Enable 64 bit environment, ppc64 x86_64, for all +universal builds (mww in r32194).
May I change this so that we only build 32-bit versions again, please? I've already encountered ports that built fine as 32-bit universals that fail as 64-bit universals. Also, we still haven't thought of a solution for all the users who already have 32-bit +universal ports installed. What happens when they upgrade to a version of MacPorts that includes this change and continue building +universal ports? Everything goes to Hell, that's what happens, because the new ports want to build 4 architectures but the existing dependencies are only built with 2 architectures.
That was the main reason for bringing it up in the Changelog, trunk has been broken for weeks... It's OK to build 64-bit universals if desired, but it should not be the default and it should be configurable - and if it builds 32-bit binaries without +universal, it should build with it too. --anders
On Jan 17, 2008, at 2:27 AM, Ryan Schmidt wrote:
[snip]
+ - Enable 64 bit environment, ppc64 x86_64, for all +universal builds (mww in r32194).
May I change this so that we only build 32-bit versions again, please? I've already encountered ports that built fine as 32-bit universals that fail as 64-bit universals. Also, we still haven't thought of a solution for all the users who already have 32-bit +universal ports installed. What happens when they upgrade to a version of MacPorts that includes this change and continue building +universal ports? Everything goes to Hell, that's what happens, because the new ports want to build 4 architectures but the existing dependencies are only built with 2 architectures.
If nobody offers a clear objection to this in 72 hours I'll change it to just the two 32-bit architectures again.
Thanks for bringing this up, Ryan, take a look at my recent message about the upcoming 1.6.1 release. I'm keeping this change out of the release_1_6 branch for now, pending mww's advise for merging or not. However, if the situation is as bad as you describe, not only will I keep it out of 1.6.1 for longer, but I'd also vote for the decision to build 64bits to be reverted. Lets please hear what Markus has to say about it first. Regards,... -jmpp
It's OK to build 64-bit universals if desired, but it should not be the default and it should be configurable - and if it builds 32-bit binaries without +universal, it should build with it too.
Also, it would be more "universal" if it was to use the 10.4u SDK on Leopard too, since then the generated binaries would work on Tiger in addition. (currently it uses the 10.5 SDK if available) --anders
On Jan 17, 2008, at 01:44, Anders F Björklund wrote:
It's OK to build 64-bit universals if desired, but it should not be the default and it should be configurable - and if it builds 32- bit binaries without +universal, it should build with it too.
Also, it would be more "universal" if it was to use the 10.4u SDK on Leopard too, since then the generated binaries would work on Tiger in addition. (currently it uses the 10.5 SDK if available)
Yes, but I understood that it was changed to use the 10.5 SDK on Leopard because using the 10.4u SDK on Leopard was broken?
Ryan Schmidt wrote:
Also, it would be more "universal" if it was to use the 10.4u SDK on Leopard too, since then the generated binaries would work on Tiger in addition. (currently it uses the 10.5 SDK if available)
Yes, but I understood that it was changed to use the 10.5 SDK on Leopard because using the 10.4u SDK on Leopard was broken?
No, the usage of it was broken. It wasn't setting MACOSX_DEPLOYMENT_TARGET (to use 10.4) "ld: library not found for -lcrt1.10.5.o" Changing to the 10.5 SDK made the problem "go away", since it would work with M_D_T=10.5 --anders
On Jan 17, 2008, at 02:46, Anders F Björklund wrote:
Ryan Schmidt wrote:
Also, it would be more "universal" if it was to use the 10.4u SDK on Leopard too, since then the generated binaries would work on Tiger in addition. (currently it uses the 10.5 SDK if available)
Yes, but I understood that it was changed to use the 10.5 SDK on Leopard because using the 10.4u SDK on Leopard was broken?
No, the usage of it was broken. It wasn't setting MACOSX_DEPLOYMENT_TARGET (to use 10.4)
"ld: library not found for -lcrt1.10.5.o"
Changing to the 10.5 SDK made the problem "go away", since it would work with M_D_T=10.5
Oh I see! Then yes, by all means, we should use the 10.4u SDK and set MACOSX_DEPLOYMENT_TARGET to 10.4.
On Thu, Jan 17, 2008 at 02:58:35AM -0600, Ryan Schmidt wrote:
On Jan 17, 2008, at 02:46, Anders F Bj?rklund wrote:
Ryan Schmidt wrote:
Also, it would be more "universal" if it was to use the 10.4u SDK on Leopard too, since then the generated binaries would work on Tiger in addition. (currently it uses the 10.5 SDK if available)
Yes, but I understood that it was changed to use the 10.5 SDK on Leopard because using the 10.4u SDK on Leopard was broken?
No, the usage of it was broken. It wasn't setting MACOSX_DEPLOYMENT_TARGET (to use 10.4)
"ld: library not found for -lcrt1.10.5.o"
Changing to the 10.5 SDK made the problem "go away", since it would work with M_D_T=10.5
Oh I see! Then yes, by all means, we should use the 10.4u SDK and set MACOSX_DEPLOYMENT_TARGET to 10.4.
Mmm, this sounds like the idea is "build for Tiger if we're on Leopard" even if the user will never use the ports on Tiger. What's being given up by using the 10.4 SDK instead of 10.5 (i.e. what fixes, enhancements, etc.)? If there's no real difference, fine. If there is a difference, I think it should be an option for those who are going to build on Leopard and share with Tiger systems, otherwise use the platform-native SDKs. -eric
On Jan 17, 2008, at 12:14 PM, Eric Hall wrote:
On Thu, Jan 17, 2008 at 02:58:35AM -0600, Ryan Schmidt wrote:
On Jan 17, 2008, at 02:46, Anders F Bj?rklund wrote:
Ryan Schmidt wrote:
Also, it would be more "universal" if it was to use the 10.4u SDK on Leopard too, since then the generated binaries would work on Tiger in addition. (currently it uses the 10.5 SDK if available)
Yes, but I understood that it was changed to use the 10.5 SDK on Leopard because using the 10.4u SDK on Leopard was broken?
No, the usage of it was broken. It wasn't setting MACOSX_DEPLOYMENT_TARGET (to use 10.4)
"ld: library not found for -lcrt1.10.5.o"
Changing to the 10.5 SDK made the problem "go away", since it would work with M_D_T=10.5
Oh I see! Then yes, by all means, we should use the 10.4u SDK and set MACOSX_DEPLOYMENT_TARGET to 10.4.
Mmm, this sounds like the idea is "build for Tiger if we're on Leopard" even if the user will never use the ports on Tiger. What's being given up by using the 10.4 SDK instead of 10.5 (i.e. what fixes, enhancements, etc.)? If there's no real difference, fine. If there is a difference, I think it should be an option for those who are going to build on Leopard and share with Tiger systems, otherwise use the platform- native SDKs.
-eric
Seconded all the way! We could have macports.conf settings for both, a) the OS's the users wishes to build for, Leopard and/or Tiger and/or Panther, and b) the desired architectures, Intel and/or PowerPc and 32 and/or 64 bits. But in the mean time, while we still don't have that level of abstraction (we don't, right?), it seems more logical to me to build as native as possible. Now, universal advocates, hold your horses! I'm not arguing against universal support itself; I am arguing, though, against universal support hampering in any way native builds, which I'm positive is what a considerable majority of MacPorts users do and need. Regards,... -jmpp
On Jan 17, 2008, at 11:08, Juan Manuel Palacios wrote:
On Jan 17, 2008, at 12:14 PM, Eric Hall wrote:
On Thu, Jan 17, 2008 at 02:58:35AM -0600, Ryan Schmidt wrote:
On Jan 17, 2008, at 02:46, Anders F Bj?rklund wrote:
Ryan Schmidt wrote:
Also, it would be more "universal" if it was to use the 10.4u SDK on Leopard too, since then the generated binaries would work on Tiger in addition. (currently it uses the 10.5 SDK if available)
Yes, but I understood that it was changed to use the 10.5 SDK on Leopard because using the 10.4u SDK on Leopard was broken?
No, the usage of it was broken. It wasn't setting MACOSX_DEPLOYMENT_TARGET (to use 10.4)
"ld: library not found for -lcrt1.10.5.o"
Changing to the 10.5 SDK made the problem "go away", since it would work with M_D_T=10.5
Oh I see! Then yes, by all means, we should use the 10.4u SDK and set MACOSX_DEPLOYMENT_TARGET to 10.4.
Mmm, this sounds like the idea is "build for Tiger if we're on Leopard" even if the user will never use the ports on Tiger. What's being given up by using the 10.4 SDK instead of 10.5 (i.e. what fixes, enhancements, etc.)? If there's no real difference, fine. If there is a difference, I think it should be an option for those who are going to build on Leopard and share with Tiger systems, otherwise use the platform- native SDKs.
Seconded all the way!
We could have macports.conf settings for both, a) the OS's the users wishes to build for, Leopard and/or Tiger and/or Panther, and b) the desired architectures, Intel and/or PowerPc and 32 and/or 64 bits. But in the mean time, while we still don't have that level of abstraction (we don't, right?), it seems more logical to me to build as native as possible. Now, universal advocates, hold your horses! I'm not arguing against universal support itself; I am arguing, though, against universal support hampering in any way native builds, which I'm positive is what a considerable majority of MacPorts users do and need.
The SDK is only used to build a universal binary, when using the +universal variant. The only users who will be using that option are those who by definition want to share the binary with other machines. Ok, maybe they want to share the binary only between Leopard machines. But I still think it's a relatively safe assumption to use the 10.4u SDK when building a universal binary. Until we start having ports for Leopard-only applications... As it is now, a port built +universal on Leopard is different from a port built +universal on Tiger, and that tastes wrong. But maybe that's just the way it has to be? What will happen when we get binary packages of ports? Will we have to have separate binaries for each cat? I guess maybe we will. We already have the problem that ports built +universal on Tiger won't be usable on Panther, so we'd need separate binaries for Panther anyway.
On Jan 17, 2008, at 12:45 PM, Ryan Schmidt wrote:
Mmm, this sounds like the idea is "build for Tiger if we're on Leopard" even if the user will never use the ports on Tiger. What's being given up by using the 10.4 SDK instead of 10.5 (i.e. what fixes, enhancements, etc.)? If there's no real difference, fine. If there is a difference, I think it should be an option for those who are going to build on Leopard and share with Tiger systems, otherwise use the platform- native SDKs.
Seconded all the way!
We could have macports.conf settings for both, a) the OS's the users wishes to build for, Leopard and/or Tiger and/or Panther, and b) the desired architectures, Intel and/or PowerPc and 32 and/or 64 bits. But in the mean time, while we still don't have that level of abstraction (we don't, right?), it seems more logical to me to build as native as possible. Now, universal advocates, hold your horses! I'm not arguing against universal support itself; I am arguing, though, against universal support hampering in any way native builds, which I'm positive is what a considerable majority of MacPorts users do and need.
The SDK is only used to build a universal binary, when using the +universal variant. The only users who will be using that option are those who by definition want to share the binary with other machines. Ok, maybe they want to share the binary only between Leopard machines. But I still think it's a relatively safe assumption to use the 10.4u SDK when building a universal binary. Until we start having ports for Leopard-only applications...
Oohhh, I see, wasn't too aware that these SDKs are used only for universal builds. Sorry for commenting rather blindly, maybe I should have looked at the source before posting. So, in this case, I wouldn't be opposed to using the Tiger SDK when building universal on Leopard, although it'd still be advisable finding out if there are any major losses to doing, as Eric questioned originally. Going forward, what I'd really like to see is an abstraction of these settings into macports.conf. Anders tells me there are three important settings to look after: 1) sysroot, the SDK employed; 2) MACOSX_DEPLOYMENT_TARGET: what's the state of these at the moment, what are we using? 3) archs, 32 Vs. 64 bits: according to Anders' last change, we're back at building only 32 bits for both Intel and PowerPC, which is what I believe we should stick to until we figure out a transparent migration path to 4-way built binaries. We should ship 1.6.1 with the most sensible possible set of defaults for all these three settings and then work toward abstracting them into macports.conf keys.
As it is now, a port built +universal on Leopard is different from a port built +universal on Tiger, and that tastes wrong.
Different how? Sorry if it's been discussed already and I'm just not keeping up with this topic. The way I understand it, there are two approaches: *) 1st: build universal but solely for Tiger, then I'd expect the binary to work either on Intel or PowerPC, but in both cases on Tiger only; build universal but solely for Leopard, then I'd expect the same thing from the binary, but on Leopard in this case. *) 2nd: we could certainly switch the SDK to 10.4 on Leopard, but then a binary built in this environment would work on any combination of Tiger and/or Leopard with PowerPC and/or Intel; on the other hand, a binary built universal on Tiger would not enjoy the same diversity, and this does constitute different "universal realities" (long live String Theory!), depending on the production environment. Maybe I'm universal impaired, but I don't see a clear winner between either one. What makes more sense and why? Or am I just smoking crack with my understanding of the problem and not get one bit the "As it is now, a port built +universal on Leopard is different from a port built +universal on Tiger" assertion?
But maybe that's just the way it has to be? What will happen when we get binary packages of ports? Will we have to have separate binaries for each cat?
I guess this exercise helps us prepare for the case scenario of not finding enough support to get all the needed hardware when the time comes ;-) PowerPC will eventually fade away, but the choice of multiple cats will always be with us.
I guess maybe we will. We already have the problem that ports built +universal on Tiger won't be usable on Panther, so we'd need separate binaries for Panther anyway.
Yes, certainly, but that's the boundary where you draw the line and start cutting the fat. If not, they we'd have to think about a way to build "universal" binaries on Panther that would work on Jaguar, and... uuuggghhh, don't even want to think about it!!!! Regards,... -jmpp
participants (4)
-
Anders F Björklund
-
Eric Hall
-
Juan Manuel Palacios
-
Ryan Schmidt