Universal Binaries

[Ryan Schmidt]

On Feb 23, 2007, at 12:23, Altoine Barker wrote:

> 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.

Well, again, I think each software project will probably have to be  
handled separately. Many projects will just need the standard CFLAGS  
and LDFLAGS and --disable-dependency-tracking configure option as  
Apple describes here:

http://developer.apple.com/technotes/tn2005/tn2137.html

But other software will need extra options, or will need patches to  
the code, or will need to be configured and compiled twice and lipo'd  
together. For example, I discovered recently that zlib needs a small  
patch to its Makefile to build universal, glib2 needs a patch to its  
config.h only when the build machine is ppc (to tell it to not try to  
use any ppc assembly, which it would otherwise), and cairo needs to  
be built twice and lipo'd together (or a patch may be possible as  
well). Although you're right that open-source software is usually  
designed to be cross-platform, very few open-source developers are  
familiar with the concept of universal binaries, and their build  
system may make assumptions which are no longer true when building  
universal binaries. (This is the problem with cairo.) Each port  
maintainer will need to discover on their own what is required to  
build their software universal. And even if they get the software to  
build as a universal, that doesn't necessarily mean that the software  
will *run* on the non-native architecture. It would have to be  
tested. And most port maintainers probably do not have access to both  
a ppc and an Intel Mac, which would be needed to properly test on  
both architectures.

Now, what we could think about doing is providing some kind of  
default, where +universal would use the standard CFLAGS, LDFLAGS and  
--disable-dependency-tracking, unless the port itself defines a  
+universal variant. This would allow many ports to build universal.  
However, those for which is doesn't would then be broken. Either  
building with +universal would cause compilation or configuration  
errors, which the user could then report to the maintainer, or the  
software would seem to compile and build properly, but then not  
actually run properly on the non-native architecture. It's hard to  
know until you try it, separately for each software package.

I don't see any need for a different install location. MacPorts has  
used /opt/local and should IMHO continue to do so, even if some or  
all ports become universal. MacPorts has never installed anything in / 
System and should not do so because that is part of what Apple  
provides, and it has always been MacPorts philosophy to remain  
separate from the Apple stuff.