flac dev - May 2008 - flac/metaflac 32/64 Universal OS X builds

In my experience, with the gcc compiler, cross-compiling is highly  
reliable.  If your code runs on one processor, then it will run on  
all.  Linking and such might be an issue, which you will discover  
immediately when the first person tries to run what you've built on  
their system.

It still would be great to run these tests on all four.  Actually,  
you should be able to test 32-bit and 64-bit on the same machine,  
provided that you have the release of the OS that is capable of 64- 
bit (but it might require a new test harness).  Testing 32-bit and 64- 
bit for the non-native processor should be a simple matter of handing  
off the binaries to a tester for confirmation before making a public  
release of those binaries.

There is no reason to suspect that cross-compiled binaries have any  
more errors than the native compile, at least not with Xcode and Mac  
OS X.

Brian Willoughby
Sound Consulting


On May 5, 2008, at 15:19, Erik de Castro Lopo wrote:
> Stephen F. Booth wrote:
>> I've just finished an Xcode 3.1 project file for flac and metaflac
>> that builds both tools as 32/64 bit universal binaries.  If anyone is
>> interested in either the binaries or the project, I'll be happy to
>> share them.
>
> The thing that always made me curious is how do you test these
> universal binaries. I meean automated testing. Josh already has
> a large test suite, but if you don't run that test suite on
> all four versions why bother?
>
> Sure, you can test the native compile without problems, but how
> do you test the other three? Its also the three cross-compiled
> ones which are the most likely to be wrong.
>
> Erik

Brian Willoughby wrote:
> In my experience, with the gcc compiler, cross-compiling is highly  
> reliable.
Your experience doesn't match mine.
> If your code runs on one processor, then it will run on  
> all.
That can easily break down in all sort of places. For instance, I'm
the main author of libsndfile and when Apple first announced Intel 
based machines I started getting weird bug reports about libsndfile
on Intel macs. After I spent a bunch of my very valuable time the
idiot reporting the issue finally confessed that he was compiling
libsndfile as a universal binary on PPC and then seeing bugs on
Intel.

The result of all this was a FAQ:

    http://www.mega-nerd.com/libsndfile/FAQ.html#Q018

and me adding code to libsndfile to detect when it was being compiled
as a UB and erroring out if it was.

For libsndfile, the *only* reliable way to create a 32 bit intel/
ppc UB is:

 0) configure for intel
 1) make
 2) make check
 3) configure for powerpc
 4) make
 5) make check
 6) use lipo to glue together the test binaries generated in
    steps 1) and 4)

Feel free to add more steps for 64 bit.
> Linking and such might be an issue, which you will discover  
> immediately when the first person tries to run what you've built on  
> their system.
In the libsndfile case it linked fine, but didn't read or write
files correctly. This could easily have resulted in people
losing valuable work.
> It still would be great to run these tests on all four.
I have a saying 'untested code is broken code'. In this case
that should read 'an untested binary is a broken binary'.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"I've nothing against OO, I do have something against C++. Its a dogs
dinner. Anyone who's (tried) to read Stroustrups book on C++ like I had
the misfortune of doing knows that the man is very intelligent but has
about as much clarity of thought as Timothy Leary on a bad day."
-- NJR in comp.os.linux.development.apps

I guess I should add this to the long list of things Apple has broken  
that used to work well on NEXTSTEP (the operating system that has  
been turned into OS X).

Now that you mention it, I remember having a problem getting flac to  
cross-compile in one build step, so I just did the manual lipo glue  
that you talked about.  I assumed it was only because I was too lazy  
to figure out how to get Xcode to work, but from your report it seems  
like there is much more to the problem.

 From your steps, it seems that it is possible to cross-compile, but  
only if you build one architecture at a time and then manually lipo  
them together.  If I someday find an easy fix for this, I'll let you  
know.  Then again, Stephen may have figured out the magic incantation  
for Xcode to make this work as simply as it should.

So, tell me, Erik: Can you build for Intel on PPC?  Can you build for  
PPC on Intel?  If you're willing to do the manual lipo steps, is that  
all you need to do to make a UB? ... or do you actually need both an  
Intel Mac and a PowerPC Mac?

Thanks for the report.

Brian Willoughby
Sound Consulting


On May 5, 2008, at 16:38, Erik de Castro Lopo wrote:
> Brian Willoughby wrote:
>> In my experience, with the gcc compiler, cross-compiling is highly
>> reliable.
>
> Your experience doesn't match mine.
>
>> If your code runs on one processor, then it will run on
>> all.
>
> That can easily break down in all sort of places. For instance, I'm
> the main author of libsndfile and when Apple first announced Intel
> based machines I started getting weird bug reports about libsndfile
> on Intel macs. After I spent a bunch of my very valuable time the
> idiot reporting the issue finally confessed that he was compiling
> libsndfile as a universal binary on PPC and then seeing bugs on
> Intel.
>
> The result of all this was a FAQ:
>
>     http://www.mega-nerd.com/libsndfile/FAQ.html#Q018
>
> and me adding code to libsndfile to detect when it was being compiled
> as a UB and erroring out if it was.
>
> For libsndfile, the *only* reliable way to create a 32 bit intel/
> ppc UB is:
>
>  0) configure for intel
>  1) make
>  2) make check
>  3) configure for powerpc
>  4) make
>  5) make check
>  6) use lipo to glue together the test binaries generated in
>     steps 1) and 4)
>
> Feel free to add more steps for 64 bit.
>
>> Linking and such might be an issue, which you will discover
>> immediately when the first person tries to run what you've built on
>> their system.
>
> In the libsndfile case it linked fine, but didn't read or write
> files correctly. This could easily have resulted in people
> losing valuable work.
>
>> It still would be great to run these tests on all four.
>
> I have a saying 'untested code is broken code'. In this case
> that should read 'an untested binary is a broken binary'.
>
> Erik