[Help] Compiling Firefox 9.0.1 for/on Pogoplug (armv5)

[cyberic]

$this->bbcode_second_pass_quote('WarheadsSE', 'q')emu- eww.

[Kurlon]

$this->bbcode_second_pass_code('', '/usr/bin/ld: BFD (GNU Binutils) 2.22.0.20111227 assertion fail /build/src/binutils/bfd/elf32-arm.c:12049
../../gfx/ycbcr/ycbcr_to_rgb565.o: In function `mozilla::gfx::ScaleYCbCrToRGB565(unsigned char const*, unsigned char const*, unsigned char const*, unsigned char*, int, int, int, int, int, int, int, int, int, mozilla::gfx::YUVType, mozilla::gfx::ScaleFilter)':
/home/jcoombs/src/mozilla-beta/gfx/ycbcr/ycbcr_to_rgb565.cpp:569: undefined reference to `mozilla::arm_private::neon_enabled'
../../gfx/ycbcr/ycbcr_to_rgb565.o: In function `mozilla::gfx::IsScaleYCbCrToRGB565Fast(int, int, int, int, int, int, mozilla::gfx::YUVType, mozilla::gfx::ScaleFilter)':
/home/jcoombs/src/mozilla-beta/gfx/ycbcr/ycbcr_to_rgb565.cpp:600: undefined reference to `mozilla::arm_private::neon_enabled'
../../gfx/ycbcr/ycbcr_to_rgb565.o: In function `mozilla::gfx::ConvertYCbCrToRGB565(unsigned char const*, unsigned char const*, unsigned char const*, unsigned char*, int, int, int, int, int, int, int, mozilla::gfx::YUVType)':
/home/jcoombs/src/mozilla-beta/gfx/ycbcr/ycbcr_to_rgb565.cpp:683: undefined reference to `mozilla::arm_private::neon_enabled'
../../gfx/ycbcr/ycbcr_to_rgb565.o: In function `mozilla::gfx::IsConvertYCbCrToRGB565Fast(int, int, int, int, mozilla::gfx::YUVType)':
/home/jcoombs/src/mozilla-beta/gfx/ycbcr/ycbcr_to_rgb565.cpp:696: undefined reference to `mozilla::arm_private::neon_enabled'
collect2: ld returned 1 exit status
make[3]: *** [libxul.so] Error 1
make[3]: Leaving directory `/home/jcoombs/src/mozilla-beta/toolkit/library'
make[2]: *** [libs_tier_platform] Error 2
make[2]: Leaving directory `/home/jcoombs/src/mozilla-beta'
make[1]: *** [tier_platform] Error 2
make[1]: Leaving directory `/home/jcoombs/src/mozilla-beta'
make: *** [default] Error 2
')

Bah, still failing on neon even with the patch to disable it.

[Kurlon]

The patch to disable the neon tests doesn't seem to actually disable the neon tests looking at configure's output. I'ma get a bit more 'agressive' about the matter and try again.

[WarheadsSE]

$this->bbcode_second_pass_quote('cyberic', '')$this->bbcode_second_pass_quote('WarheadsSE', 'q')emu- eww.

[kmihelich]

Qemu was investigated before I settled on the distcc ct-ng setup that has been the backbone of this distribution for over a year now. Qemu simply fails in ways you don't see during builds but become fatal during execution. You're free to use it, but I won't touch anything that is a product of that process.

[moonman]

$this->bbcode_second_pass_quote('pepedog', 'I') wish you never 7 zipped it, can you do in another format please?

[cyberic]

$this->bbcode_second_pass_quote('kmihelich', 'Q')emu simply fails in ways you don't see during builds but become fatal during execution.

[WarheadsSE]

Let me put it this way:
Have you ever used a gaming system emulator like zsnes or jnes? You know how occasionally they don't quite behave, or if pushed just right hang horribly? Take that, apply it to any program compiled inside the emulator, but use on a real system.

[cyberic]

I see and I understand your point.
But I find that ct-ng is not that clean neather: there can be some subtile differneces between native compilers and cross compilers, that may also lead to erroneous compilation or beheaviour. don't you think?

[kmihelich]

Since the official ct-ng environment used in the build system is built from the same gcc/glibc/binutils source tarballs as the versions used natively (I do this specially, not included in instructions), there is very very little deviation. Also, since it's just the compile portion being exported to a faster box, all of the pre-processing and linking is taken care of in the native environment, using all of the native libraries and headers in the correct locations without any tricks.

There may be subtle differences, but if you can find them I'll make you some cookies.

WarheadsSE put it perfectly in regard to Qemu. Everything really does look like it's going fine, might act fine in simple tests, but in the production environment things start going very wrong unexpectedly. We tried this like I said, and it just doesn't work. Add the fact that Qemu even on a fast x86 box is magnitudes slower than the distcc ct-ng setup used now, and it's really not worth it.