Universal Binaries

Jordan K. Hubbard jkh at brierdr.com
Fri Feb 23 13:37:44 PST 2007


I think you're starting with a fundamental premise that Universal  
binaries are something of an optional frill (and that they somehow  
use more memory than non-universal ones) - neither statement is,  
unfortunately, true.

First, you have to remember that even people who "build all their own  
bits" are still going to run into scenarios where the bits they build  
on MachineA would be useful on MachineB and they'd rather just copy a  
tree over than wait multiple hours for something like KDE or xemacs  
to build from scratch every single time they want it on a new machine  
(and even if you only own a single machine, eventually you're going  
to come up against the upgrade case where Migration Assistant will  
helpfully copy all your old bits, including /opt, onto the new  
machine and do you really want to run all your MacPorts stuff under  
Rosetta?).   Right now, the large majority of Mac users are still  
using PPC machines (consider the installed base) but this balance is  
tipping more and more every day as the Mac installed base actually  
expands and enjoys a rate of growth far in excess of traditional PC  
market growth (yay).  Building universal as a DEFAULT position means  
that this change is essentially painless as people switch machines,  
get new machines to slide next to existing ones, and so on.   Yes,  
it's a fair amount of pain for us, the producers of MacPorts, but  
that's just the nature of the beast - developers are accustomed to  
suffering pain once so that end-users do not have to suffer it  
multiple times. :-)

At Apple, we build everything universal and that includes a LOT of  
open source.  It's sometimes a bit of a pain to beat it into  
compliance, but surprisingly not all that much pain.

Second, universal binaries do NOT use more memory than non-universal  
ones.  They take up a little more space on disk, but only the bits  
relevant to your architecture are actually loaded into memory.   What  
DOES take a lot more memory is running PPC binaries under Rosetta,  
which essentially needs to translate and cache the results of code  
morphing on the fly.

- Jordan

On Feb 23, 2007, at 10:23 AM, Altoine Barker wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm reading up on universal binaries and such now. I see your point  
> but
> I think it should be an option or flag that you can choose for any
> particular port and not default for all ports, unless, an option to
> choose to the contrary is selected to address memory space issues.  
> I see
> a need for what you are talking about and I desire such functionality
> with the idea environment, which I do not have but you do. I would  
> like
> to sign up for such a cause, except, I am trying to get a few of my  
> own
> projects to the point where I would then need to look at macports
> providing universal binary support. I think the premise of macports is
> to be self-supporting without bloat for those that seek such a  
> feature.
>
> I agree for an enhanced macports that has that as an option and not
> default. Since most open source code is written to be cross-platform,
> there shouldn't be too many problems. Alot of work, but not too many
> problems. Of course, an ability to choose the location of or a default
> one created (i.e. /opt/local/universal) You wouldn't want to put it
> under /System/Library/Frameworks since an update may flush your
> universal ports. My $0.02.
>
> - -Altoine
>
> P.S. On further reading, I see it being possible. I just am not at  
> that
> point in my goals to incorporate that task. I am more than  
> available to
> test but I can not start or join such an endeavor until I finish a few
> that I have now.
>
>
> Jordan K. Hubbard wrote:
>> Is that one of them-there rhetorical questions? :-)
>>
>> There are lots of good reasons to want universal binaries.   For  
>> one, it
>> allows you to NFS/AFP/... share a single /opt/local among machines  
>> (who
>> says that directory always has to be local?) without having to worry
>> about which architecture those machines are.   It also allows you to
>> archive up a carefully built-up /opt/local (+ /Applications/ 
>> DarwinPorts)
>> and give it to other people, of course.
>>
>> Finally, perhaps the best reason for building universal is the  
>> eventual
>> (any year now, I'm sure, and almost certainly by the next millennium)
>> move to releasing packaged versions of MacPorts software, complete  
>> with
>> dependency tracking.  You don't want to have 2 sets of packages
>> (assuming that only 32 bit ABIs are important) in what would  
>> eventually
>> be a multi-thousand package archive.
>>
>> Universal Binaries are definitely the way forward on the Mac and  
>> porters
>> should be encouraged to shoot for them as the rule rather than the
>> exception.   If disk space is a problem for any of the targets  
>> (and it's
>> not that big an increase), they can always be thinned post-install  
>> time.
>>
>> - Jordan
>>
>> On Feb 23, 2007, at 7:35 AM, Kevin Ballard wrote:
>>
>>> I'm curious as to why you want universal binaries. In general,
>>> binaries produced via MacPorts can't be copied between platforms, as
>>> they need all the libraries they depend on. Sure, you can copy your
>>> entire MacPorts /opt/local tree, but outside of doing that it's  
>>> quite
>>> hard to migrate the built products.
>>>
>>> Given that, what benefit do you get from universal binaries?
>>>
>>> On Feb 22, 2007, at 5:23 PM, Ryan Schmidt wrote:
>>>
>>>> On Feb 22, 2007, at 02:35, Nathan Brazil wrote:
>>>>
>>>>> Hi.  Is it possible to produce universal binaries from MacPorts?
>>>>> For example, are the GTK+ binaries produced from MacPorts specific
>>>>> to the architecture of the machine it is produced on (PPC vs  
>>>>> Intel),
>>>>> or is there a way to produce binaries that will work natively  
>>>>> on both?
>>>>
>>>> MacPorts produces platform-native binaries. There is no way to
>>>> produce universal binaries. For many projects, it is a simple  
>>>> matter
>>>> to produce universal binaries. However, some projects need to be
>>>> handled specially, so MacPorts cannot provide a guaranteed way of
>>>> automatically building universal binaries of all software. A  
>>>> very few
>>>> ports provide a +universal variant.
>>>
>>> -- 
>>> Kevin Ballard
>>> http://kevin.sb.org
>>> eridius at macports.org <mailto:eridius at macports.org>
>>> http://www.tildesoft.com
>>>
>>>
>>> _______________________________________________
>>> macports-users mailing list
>>> macports-users at lists.macosforge.org
>>> <mailto:macports-users at lists.macosforge.org>
>>> http://lists.macosforge.org/mailman/listinfo/macports-users
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> macports-users mailing list
>> macports-users at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/macports-users
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF3zExS0foIafBdlkRAl88AKCkLDpxpoNorS5lIB03zjQXL7nfPQCdELCy
> LBZWVLevtpQx3Rb7O65/aeM=
> =rWsl
> -----END PGP SIGNATURE-----
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-users




More information about the macports-users mailing list