Emerging Firefox on ARM - how do I disable Neon?

[aahjnnot]

Attempting to emerge Firefox 24.3.0 on my Raspberry Pi 2 gives the following error:

Code: Select all

../../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)':
ycbcr_to_rgb565.cpp:(.text._ZN7mozilla3gfx20ConvertYCbCrToRGB565EPKhS2_S2_PhiiiiiiiNS0_7YUVTypeE+0xc0): undefined reference to `mozilla::gfx::yuv42x_to_rgb565_row_neon(unsigned short*, unsigned char const*, unsigned char const*, unsigned char const*, int, int)'
collect2: error: ld returned 1 exit status
distcc[4976] ERROR: compile (null) on localhost failed
/var/tmp/portage/www-client/firefox-24.3.0/work/mozilla-esr24/config/rules.mk:1023: recipe for target 'libxul.so' failed
make[5]: *** [libxul.so] Error 1

Googling the error finds multiple bug reports for the problem both upstream and with various Linux distributions. Unfortunately, I can't find a clear solution.

The issue appears to be a misdetection of Neon FPU capability. Users of other distributions have reported success by compiling with the Neon capability disabled, but I can't work out how to do that with Gentoo and Portage (I'm a newbie here, having previously only used Ubuntu).

Firefox doesn't appear to have a Neon USE flag that I can disable, so I've tried fiddling with CFLAGS in /etc/portage/make.conf. Here are my before and after efforts:

Before:

Code: Select all

CFLAGS="-O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"

After:

Code: Select all

CFLAGS="-O2 -mcpu=cortex-a7 -mfpu=vfpv4 -mfloat-abi=hard"

Both setting produce the same error. How do I disable Neon?

[Leio]

Disabling NEON doesn't sound right. Pi 2 supports NEON and you should use it whenever possible. You should globally enable that USE flag, etc.
The real problem is ancient Firefox probably. Go ~arm

[redgee34]

Changing python version helped... just in case someone else stumbles on this issue:

[UncleVan]

Yes, Im stumbling on this issue since yesterday - Im trying to compile www-client/firefox-24.3.0 on my RasPi Model 1 - no neon support, of course; distcc without pump - and Im getting pretty reproducable after 5115 compiled *.o's:

Code: Select all

../../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)':
ycbcr_to_rgb565.cpp:(.text._ZN7mozilla3gfx20ConvertYCbCrToRGB565EPKhS2_S2_PhiiiiiiiNS0_7YUVTypeE+0xc0): undefined reference to `mozilla::gfx::yuv42x_to_rgb565_row_neon(unsigned short*, unsigned char const*, unsigned char const*, unsigned char const*, int, int)'

Any ideas how to disable neon on Pi 1 ?

Thank you in advance !

PS: Yes Leio, Im trying www-client/firefox-31.5.0 right now, but it will take at least 12h till I know....(or if Im "lucky" it will abort in the next 30 minutes )

[UncleVan]

Well, small excerpt from configure.in (www-client/firefox-24.3.0) :

Code: Select all

        dnl These flags are a lie; they're just used to enable the requisite
        dnl opcodes; actual arch detection is done at runtime.
        VPX_ASFLAGS="-march=armv7-a -mfpu=neon"

According to this it allways has to generate neon code; wonder whether this is possible with the armv6j-hardfloat-linux-gnueabi-g++/gcc/as ? AFAIK neon is only abailable with some Cortex arch's... Got to do further investigations.

[UncleVan]

I found the error and issued a patch to fix it.
(@redgee34: Can not confirm that changing Python version somehow fixes this)

Basically Firefox is designed so, it generates all the specific code for various arm flavors - including the neon one - and resolves the actual plattform at run time.

But there is a bug in Mozilla's build system, carried out by files called moz.build with Python syntax which are supposed to generate the Makefile targets. Specifically there are some lousy checks on a Make variable called OS_TEST:

Code: Select all

$ find /mnt/custom/www-client/firefox-24.3.0/work/ -name moz.build -exec grep -3 OS_TEST {} \; -print | grep -3 arm
...
if CONFIG['OS_TEST'] == 'arm' and CONFIG['HAVE_ARM_NEON']:
    CPP_SOURCES += [
        'yuv_convert_arm.cpp',
    ]
/mnt/custom/www-client/firefox-24.3.0/work/mozilla-esr24/gfx/ycbcr/moz.build
MODULE = 'xpcom'
--
            'xptcinvoke_gcc_x86_unix.cpp',
            'xptcstubs_gcc_x86_unix.cpp',
        ]
    elif CONFIG['OS_TEST'] == 'arm':
        CPP_SOURCES += [
            'xptcinvoke_nto_arm.cpp',
            'xptcstubs_nto_arm.cpp',
        ]
    elif CONFIG['OS_TEST'] == 'sh':
        CPP_SOURCES += [
--
            'xptcstubs_alpha_openbsd.cpp',
        ]

if CONFIG['OS_TEST'].startswith('arm') or CONFIG['OS_TEST'] == 'sa110':
    if CONFIG['OS_ARCH'] == 'Linux':
        CPP_SOURCES += [
            'xptcinvoke_arm.cpp',
--
            'xptcstubs_arm_netbsd.cpp',
        ]

Particularly the first one was the culprit (ycbcr/moz.build), it should be better startswith('arm') like the last one, because the Autoconfig tends to set OS_TEST to ${target_cpu}, which is something like "armv6j" for me; or - I guess - "armv7a" for RasPi 2 :

Code: Select all

$ cat /mnt/custom/www-client/firefox-24.3.0/work/mozilla-esr24/configure.in | grep OS_TEST
  1030	OS_TEST="${target_cpu}"
  1047	# OS_TEST
  1089	        OS_TEST=`uname -p`
  1120	    OS_TEST=${target_cpu}
  1130	        OS_TEST=ppc
  1133	        OS_TEST=i386
  1136	        OS_TEST=x86_64
  1140	            OS_TEST=`uname -p`
  1147	# Only set CPU_ARCH if we recognize the value of OS_TEST
  1149	case "$OS_TEST" in
  1183	    CPU_ARCH="$OS_TEST"
  1203	case "$OS_TEST" in
  6120	  case "$OS_ARCH:$OS_TEST" in
  8948	AC_SUBST(OS_TEST)

(uname -p returns "unknown" on RasPi 1 )

Code: Select all

$ cat /mnt/custom/www-client/firefox-24.3.0/work/mozilla-esr24/obj-armv6l-unknown-linux-gnueabi/config.status | grep OS_TEST    (''' OS_TEST ''', r''' armv6j '''),

Thus the "yuv_convert_arm.cpp" never makes it to an object file and after exactly 5115 *.o's ld (the linker) complains about unresolved reference to "yuv42x_to_rgb565_row_neon(....)" - the only function yuv_convert_arm.cpp implements.

Strangely they marked as "stable" just that version of firefox which is garanteed to not compile ...

As I didnt want to mess with the original build system I decided to put a [[[ $OS_TEST == arm* ]]] && OS_TEST=arm in the central configure.in (guess why 3 of []..)

With OS_TEST=arm the check catches and the compilation succeeds so firefox emerges correctly - they call it Aurora for arm... But performes poorly on a RasPi 1.

Here is the patch: https://bpaste.net/show/51c484d2bd61 . Copy & paste it into /etc/portage/patches/www-client/firefox-24.3.0/UncleVan-5115-os-test-arm.patch in order to get picked up by emerge. Then issue

Code: Select all

emerge www-client/firefox

lean back and enjoy the show; 9:30h on my RPi 1 .... With cross-distcc !

Should also work on RasPi 2 - report your experience .

Your UncleVan.

[Slavok47]

Hello everyone, I am suffering for several days with a similar problem, the device Banana PRO help solve the problem. thank you!