Re: [xml] Intel Mac supported?

On Feb 5, 2006, Steve Ball <Steve Ball explain com au> wrote:

I haven't yet built the frameworks as Universal Binaries, but I'm not
anticipating any difficulty there.  I've seen plenty of discussion
and doco on how to do this.  Since I do not have an Intel Mac, there
hasn't been any motivation to change the build process (btw,
donations to the "buy Steve a Mac Book Pro so he'll build Universal
Binaries" fund will be gratefully accepted ;-)

Since Apple ships libxml2 preinstalled, I'd say it's a pretty safe bet
that somebody has built it universal.  :-)

Actually, more to to the point, I'm certain of it, since I maintain some
command-line XML tools and I've built and run them on Intel-based
Mac OS X, so I'm certain that they've built it universal.  I don't know
what mechanism they used, though---probably the build-separately-
and-glue-together method, which is less than ideal in terms of
build time (since it requires multiple passes across the tree), but
the same time, always works.

Anyway, here's what you should expect:

1.      If there are any tests for byte order or data type sizes that occur
during autoconf rather than during the make or at runtime, you
should fix those.  Either use endianness macros or conditional
byte swaps like htons/htonl rather than hand rolling the equivalent.

2.      If for some reason you aren't able to add CFLAGS or LDFLAGS
to the build process by prefixing the make instruction, you might
have to make changes.  In other words, the following should result
in extra flags being passed to gcc:

CFLAGS="-arch ppc -arch i386" make

3.      If you use gcc to run ld, you must do so consistently.  If you use
ld directly, you must do so consistently.  The first is preferred, since
that way you can build 3-way universal with 64-bit PowerPC.  (You
currently have to use a different linker if you include ppc64 object
code, but I don't know if that will always be the case.)

        If you do not consistently use one or the other, you will not be
able to safely pass in arch flags to the linker, since the syntax for
doing so depends on whether you are passing them to the linker
directly or through gcc with the -W flag.

4.      If worst comes to worst, you can always build the two in separate
build roots, then lipo the binaries together. This isn't the recommended
solution, but it is the only one that is always guaranteed to work no
matter what the configure/makefile setup looks like.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]