I am talking about Apple's transition from PowerPC to Intel
processors. Although PPC code can be run in emulation on Intel-based
Macs, it is of course better to provide native binaries. Therefor,
binaries on the Mac can be so called "universal binaries". They
consist of a part that is used as the binary is run on a PPC and
another part that is used when it's Intel. In order for my Cocoa
(Apple's programming framework) application to be able to compiled in
this manner, it needs its frameworks/libraries compiled in such way
The instructions William gave me allow me to glue a version compiled
for PPC and a version for Intel together using lipo.
_From what I understand from the whole matter now, is that if the
LDFLAGS aren't set as Apple suggest, netcdf would compile. The only
thing then is the line in ncconfig.h which toggles the handling of big
vs. little endian. It seems that right now this is set during the
configure stage, whereas if it was set during compilation both the PPC
and Intel architecture could be built in one go.
This is under the assumption btw, that the instructions as by William
do actually work. Since both he nor me have access yet to an Intel Mac
to test this, we can't be sure about it. At least it does compile and
it lets me compile my own application successfully as an universal
binary and it works on the PPC.
"make test" fails because it uses "ar" which doesn't support the
universal binaries. Apple recommends using libtool for those purposes.
It's good to hear that netcdf will switch to using libtool with 4.0.
Hopefully that will enable the "make test" to run successfully.
I don't know about other open source packages that use libtool. To be
honest, I hardly know what ar and libtool are used for.
I just checked, and indeed, if I don't set the LDFLAGS, netcdf
compiles for both Intel and PPC:
% file libsrc/libnetcdf.a
libsrc/libnetcdf.a: Mach-O fat file with 2 architectures
libsrc/libnetcdf.a (for architecture i386): current ar archive
libsrc/libnetcdf.a (for architecture ppc): current ar archive
So that just leaves me wondering about the big endian issue.