gpanders / meta-scipy

OpenEmbedded layer for scipy (ARCHIVED)
https://github.com/tuxable-ltd/meta-scipy
MIT License
18 stars 23 forks source link

setting target FPU #2

Closed HerrMuellerluedenscheid closed 4 years ago

HerrMuellerluedenscheid commented 4 years ago

Hi,

This recipe compiles perfectly fine using qemu_x86-64 but unfortunately I'm stuck with the compilation for the target platform which is powered by an Allwinner H2 SoC. 'do_compile' fails with:

/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/ld: error: build/lib.linux-x86_64-3.7/scipy/fftpack/_fftpack.cpython-37m-arm-linux-gnueabi.so uses VFP register arguments, build/temp.linux-x86_64-3.7/libfftpack.a(cffti1.o) does not
/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/ld: failed to merge target specific data of file build/temp.linux-x86_64-3.7/libfftpack.a(cffti1.o)

[...]

| error: Command "/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc -Wall -g -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot -shared -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now -L/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot/usr/lib/python3.7/site-packages/numpy/core/lib build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/_fftpackmodule.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/zfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/drfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/zrfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/zfftnd.o build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/src/dct.o build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/src/dst.o build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/fortranobject.o -L/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot/usr/lib -Lbuild/temp.linux-x86_64-3.7 -ldfftpack -lfftpack -lpython3.7m -lgfortran -o build/lib.linux-x86_64-3.7/scipy/fftpack/_fftpack.cpython-37m-arm-linux-gnueabi.so -Wl,--version-script=build/temp.linux-x86_64-3.7/link-version-scipy.fftpack._fftpack.map" failed with exit status 1
| ERROR: 'python3 setup.py build ' execution failed.

(Note the warning on the VFP register arguments)

I did some research and assume that it is linked to the floating point processing on the target device. I tried to enforce hard and soft FPU handling by setting target_FPU="soft" (or hard) in the machine configuration. In both cases compilation crashed at the same step.

Do you have an idea how to fix the compilation for this target machine?

gpanders commented 4 years ago

Unfortunately I won't be of much help to you here. You might want to try asking on the Yocto mailing list. Someone on there might have some experience compiling to your target.

HerrMuellerluedenscheid commented 4 years ago

Ok. I'm in contact with the community throurgh their irc channel. I'll close the issue but will keep it updated as soon as a solution comes up.

mcampbellizo commented 4 years ago

@HerrMuellerluedenscheid , we ran into a similar issue when compiling for the RPi 3. Our work around was to switch to soft float ABI and disable the VFP unit. This isn't a great solution as this has an impact on performance, but it goes us going. I'd be interested in hearing if you got any better solutions from talking to the larger community.

HerrMuellerluedenscheid commented 4 years ago

@mcampbellizo Sure, I'm happy to keep you updated. For now, I would be super happy if the soft float ABI would work. Can you give me a hint on how you did that? So far I only found the TARGET_FPU switch which I set to soft but that did not do the trick, unfortunately. Given that we seem to have a pretty overpowered CPU for our task I most certainly can live with performance loss (for now).

mcampbellizo commented 4 years ago

@HerrMuellerluedenscheid we had to change the DEFAULTTUNE variable in the machine conf file (in our case conf/machine/raspberrypi3.conf. The orignal value was

DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4"

and we changed it to

DEFAULTTUNE ?= "cortexa7t-neon"

This changed from the hard float ABI To soft float ABI and disabled used of the vector floating point unit. The base cortexa7t might need to be different for your board if it's not an a7 core, but this should get you started. Let me know how this goes for you.

HerrMuellerluedenscheid commented 4 years ago

That works! I'll see how bad the performance loss is but for now this allows to compile this recipe on Allwinner H2 plus (branch: warrior)!

mcampbellizo commented 4 years ago

That's awesome! We didn't get exact numbers but did note a measurable difference in at least Scipy performance. Depending on how bad it is for us we may investigate how to get this working with hard float and VFP enabled. Either way, do you think a note about needing to disable VFP and hard float with an example in the README.md seems like a good idea?

gpanders commented 4 years ago

I've just made the wiki for this repo publicly editable, so I think that would be a good place to add things like this. You can create a new page for your particular architecture/target with specific instructions. Let me know if you're not able to do so.

yohboy commented 4 years ago

Hi, I also ran into the same issue, changing the default tune worked (a9 core). I'm curious if someone finds a way to keep hard abi.

erikboto commented 4 years ago

I'm also hitting this issue. Looking into a bit it seems like the issue is that the fortran compiler is not called with the -mfloat-abi -mfpu set as it should, so it generates soft-float binaries and then the linker complains when linking with the other objects file correctly compiled from C with correct float options.

I'll most likely be digging into this the next few days, and will provide updates here if I have any news.