| View previous topic :: View next topic |
| Author |
Message |
aahjnnot
n00b
Joined: 16 Feb 2015
Posts: 14
|
 Posted: Thu Mar 05, 2015 10:14 am Post subject: Emerging Firefox on ARM - how do I disable Neon? |
 |
|
Attempting to emerge Firefox 24.3.0 on my Raspberry Pi 2 gives the following error:
| Code: |
../../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: | | CFLAGS="-O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" |
After: | Code: | | CFLAGS="-O2 -mcpu=cortex-a7 -mfpu=vfpv4 -mfloat-abi=hard" |
Both setting produce the same error. How do I disable Neon? |
|
| Back to top |
|
 |
Leio
Developer
Joined: 27 Feb 2003
Posts: 494
Location: Estonia
|
| Posted: Fri Mar 06, 2015 5:43 am Post subject: |
|
|
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
_________________
GNOME team lead; GStreamer; MIPS/ARM64 |
|
| Back to top |
|
|
redgee34
n00b
Joined: 10 Mar 2015
Posts: 1
|
| Posted: Tue Mar 10, 2015 6:44 am Post subject: |
|
|
Changing python version helped... just in case someone else stumbles on this issue:
_________________
ahsan |
|
| Back to top |
|
|
UncleVan
n00b
Joined: 08 Feb 2011
Posts: 72
|
| Posted: Thu Mar 19, 2015 9:50 am Post subject: which Python exactly ? |
|
|
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: | ../../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  ) |
|
| Back to top |
|
|
UncleVan
n00b
Joined: 08 Feb 2011
Posts: 72
|
| Posted: Fri Mar 20, 2015 9:34 pm Post subject: |
|
|
Well, small excerpt from configure.in (www-client/firefox-24.3.0) : | Code: | 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. |
|
| Back to top |
|
|
UncleVan
n00b
Joined: 08 Feb 2011
Posts: 72
|
| Posted: Tue Mar 24, 2015 10:16 am Post subject: |
|
|
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: | $ 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: | $ 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: | | $ 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: | | 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. |
|
| Back to top |
|
|
Slavok47
n00b
Joined: 31 Mar 2015
Posts: 2
|
| Posted: Wed Apr 29, 2015 11:06 am Post subject: |
|
|
| Hello everyone, I am suffering for several days with a similar problem, the device Banana PRO help solve the problem. thank you! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
