2-architecture +universal variants please (was: Re: [32999] trunk/base/ChangeLog)

Juan Manuel Palacios jmpp at macports.org
Thu Jan 17 09:08:24 PST 2008


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



More information about the macports-dev mailing list