Do we support running i386 on OS X 10.6?
Paul Biggar
It's unclear whether we support running i386 on OS X 10.6. #build
didn't know, but they definitely don't test it. So:
- Do we support it?
- What tier?
- Should we add it as a platform in tinderbox?
For more context, we recently moved to producing only one type of
build for OS X, which is an i386/x86_64 universal binary. It is built
on 10.6. The x86_64 part is built with the native compiler, using host
headers. The i386 part is built with a cross-compiler, targeting i386,
using headers from the 10.5 SDK. We test two configurations, called
"OS X" and "OS X64", in tinderbox. "OS X" means running the universal
binary on 10.5, "OS X64" means running the universal binary on 10.6.
We do not test running the i386 part on 10.6. There are a few reasons
you might be running in this configuration:
- running 10.6 on an (old) i386 machine.
- developers testing the i386 part on their 10.6 machine.
I do not know if we _should_ support it, but we should do whichever we
decide explicitly.
Thanks,
Paul
--
Paul Biggar
Compiler Geek
pbi...@mozilla.com
Benjamin Smedberg
> It's unclear whether we support running i386 on OS X 10.6. #build
> didn't know, but they definitely don't test it. So:
>
> - Do we support it?
> - What tier?
> - Should we add it as a platform in tinderbox?
Do you really think that i386 on 10.6 is going to be significantly different
than on 10.5? I don't think the marginal difference between the two
platforms is enough to require that we test i386 on both 10.5 and 10.6. The
costs in terms of testing machines is pretty high.
--BDS
Paul Biggar
> Do you really think that i386 on 10.6 is going to be significantly different
> than on 10.5? I don't think the marginal difference between the two
> platforms is enough to require that we test i386 on both 10.5 and 10.6. The
> costs in terms of testing machines is pretty high.
No, I expect it to be subtly different, and to crash and break in
unpleasant ways. I hit upon this this yesterday:
- The structures used by Mac OSX malloc differ between 10.6 and 10.5,
and updating only the 10.5 fields causes 10.6 to break. The solution
was straightforward, but hacky.
- xp_idl was segfaulting for me this morning (though I can't
reproduce now that I try).
If we say we don't support it, fine. If we do support it but don't
have the resources to test it, we should explicitly say so, and pick
an appropriate tier for that designation.
Boris Zbarsky
> If we say we don't support it, fine. If we do support it but don't
> have the resources to test it, we should explicitly say so, and pick
> an appropriate tier for that designation.
Hmm. So at least part of the i386 stuff runs on 10.6, since the plugin
host processes are 32-bit, right? Or are we talking about code that
wouldn't be exercised by those?
-Boris
Josh Aas
We do use the i386 plugin host on Mac OS X 10.6, and I do expect that
some users will switch everything back to i386. This would be
automatic in the case of first-rev Intel machines that aren't 64-bit
(rare) and manual for users with unusual requirements like a
particular plugin that is still using Carbon NPAPI (also rare, or will
be by the time we release). Testing i386 on Mac OS X 10.5 covers a
lot, but it doesn't cover everything. If the cost is acceptable for
testing machines we should get them, but I think we can get the job
done with a bit of manual testing.
Jesse Ruderman
What if we run it once a day rather than on every checkin?
(The cost of running tests manually, and tracking down regressions
manually, is pretty high too!)
Ted Mielczarek
> On Tue, Oct 5, 2010 at 3:23 PM, Benjamin Smedberg <benj...@smedbergs.us> wrote:
>> than on 10.5? I don't think the marginal difference between the two
>> platforms is enough to require that we test i386 on both 10.5 and 10.6. The
>> costs in terms of testing machines is pretty high.
>
> unpleasant ways. I hit upon this this yesterday:
>
> - The structures used by Mac OSX malloc differ between 10.6 and 10.5,
> and updating only the 10.5 fields causes 10.6 to break. The solution
> was straightforward, but hacky.
> - xp_idl was segfaulting for me this morning (though I can't
> reproduce now that I try).
I think you've hit one particular edge case and are extrapolating too
far. Until just recently our mac release and nightly builds were
i386/ppc nightly builds built on 10.5. We've had lots of users using
them on 10.6 without any significant problems. While I agree that the
problem you've uncovered is scary and we should ensure that we don't
break things, I haven't seen any reason to believe it's endemic in
running an i386 build targeted at 10.5 on 10.6.
-Ted
Paul Biggar
> I think you've hit one particular edge case and are extrapolating too
> far.
Just to clarify, I don't think it is endemic. I suspect no-one really
considered this platform before, and that it kinda fell through the
cracks. Whichever way we go, I'd like it to be because we decided, not
because we forgot about it. I'd really just like to emerge from this
discussion with a clear answer to my first three questions.
Mike Beltzner
> Just to clarify, I don't think it is endemic. I suspect no-one really
> considered this platform before, and that it kinda fell through the
> cracks. Whichever way we go, I'd like it to be because we decided, not
> because we forgot about it. I'd really just like to emerge from this
> discussion with a clear answer to my first three questions.
Quite so! And thus, based on what I've read so far, this is where I think we're at with that:
> - Do we support it?
We support plugin-container as 32 bit on OS X 10.6, but I do not believe that at this time we have decided to support the main Firefox binary as 32 bit on OS X 10.6.
> - What tier?
plugin-container should be supported as tier 1
> - Should we add it as a platform in tinderbox?
I don't believe that we should, no. 64-bit is the bright, shiny future.
cheers,
mike