I'm stuck compiling a bitbake recipe for an Allwinner H2 SoC. It seems to be a problem of floating point unit compatibility. This is the compilation error log (abbreviated paths and added line breaks for a little better readability):
python3-scipy/1.3.3-r0/recipe-sysroot-native/[...]/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
python3-scipy/1.3.3-r0/recipe-sysroot-native/[...]/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.
I tried to enforce hard and soft FPU handling by setting target_FPU="soft", "hard" and "vfp-neon" in the machine configuration. In all cases compilation crashed at the same step. I further experimented with the compiler flags of the failing step, such as changing -mfloat-abi to soft, hard and vfp-neon. None lead to success.
Any hint on how to compile this recipe for this architecture is highly appreciated!
Edit: This is the recipe I'm trying to bitbake: meta-scipy
The error you see happen because the fortran compiler isn't passed the correct floating point arguments. I've created a pull request to meta-scipy which solves this, at least I can now build for Raspberry Pi without forcing soft-float.
This is rather a workaround but allowed to finally compile this recipe: Disable hard float ABI by changing the DEFAULTTUNE. This TUNE worked:
DEFAULTTUNE ?= "cortexa7t-neon"
As discussed here: https://github.com/gpanders/meta-scipy/issues/2#issuecomment-603266558
Related
I am utilizing yocto (dunfell) to cross-compile a project for multiple different architectures. Specifically, the targets I have are a 64-bit RaspberryPi4 (aarch64) and a 32-bit Orange Pi (armhf). My project that I am cross-compiling compiles and runs without issue when building for the raspi target; the runtime linker is properly set and things run without issue. However, whenever I build for the Orange Pi target, the program appears to compile without issue, but when I try to execute it on the platform, I get a "File not found" error.
This appears to be because the interpreter (runtime linker) is set to /usr/lib/ld.so which is not actually on the system. See below:
$ file my-exec
my-exec: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /usr/lib/ld.so.1, with debug_info, not stripped
In contrast, when I build the same program for the raspi target, the interpreter seems to be set properly for the system:
$ file my-exec
my-exec: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, with debug_info, not stripped
This issue seems to be isolated to just this project on the Orange Pi target. In comparison, other projects on the Orange Pi target look like the following and run without issue:
$ file other-exec
other-exec: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, stripped
What I am trying to understand is the following:
Which things could possibly be influencing the interpreter which is chosen at compile time? I have done some digging into this and nothing is explicitly set in my Makefile which could be causing this. Additionally, when I build a simple hello world application, the correct interpreter is chosen. It seems to be some set of flags in my compiling/linking which is causing this. Below is the compiling/linking output (I have excluded all the libraries it is also building which use the same arguments):
NOTE: make -j 24 i2c-core VERBOSE=1 CC=arm-poky-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/my-yocto-os/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/my-exec/1.0+git999-r0/recipe-sysroot LD=arm-poky-linux-gnueabi-ld --sysroot=/home/my-yocto-os/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/my-exec/1.0+git999-r0/recipe-sysroot
arm-poky-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/my-yocto-os/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/my-exec/1.0+git999-r0/recipe-sysroot -I.. -I. -g -std=gnu99 -Wall -Wextra -pedantic -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -Wno-long-long -Wconversion -Wstrict-prototypes -DBUILD_CORE -c -o build/other.o ../other.c
...
arm-poky-linux-gnueabi-ld --sysroot=/home/my-yocto-os/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/my-exec/1.0+git999-r0/recipe-sysroot build/my-exec.o build/other.o build/other1.o -luv -lsystemd -lc --entry main -o build/exe/my-exec
The linker which is being set (/usr/lib/ld.so.1) seems to be a really common linker to use, so why doesn't it actually end up on my system?
Am I fundamentally misunderstanding something about the ARM architecture which is resulting in this outcome? Are there different flags I could set at linking which would resolve this?
One further piece of information I have, which may or may not be relevant is the following:
An issue I hit while building for the Raspi target (showed up on both targets, actually) was the compiler wasn't able to find the entry symbol. This is quite a mature project and cross-compilers have been used to compile it, historically, but in a way that isn't yocto. This has never been an issue in the past. It wasn't until I added --entry main to the linker flags that this issue was resolved. I am wondering if there is a more fundamental problem which is resulting in these odd outcomes.
Thank you for any help you can provide on this. Please let me know if you have any additional questions about my environment.
After a few days of debugging, I figured out there problem. If anyone with more knowledge than I on linking would like to chime in to add things, please do. Ultimately, this was resolved by using gcc as the linker as opposed to using ld (the ones provided by yocto's cross compiler; i.e. aarch64-poky-linux-gcc).
In order to do this, I modified my recipe to pass in LD=${CC} LDFLAGS=${LDFLAGS} to my Makefile. Now, it builds and executes properly for both the RPi and OrangePi targets.
I believe this is mainly the case because the LDFLAGS provided by yocto actually can't be parsed by ld. From my research, it looks like ld is typically invoked by gcc. However, the flags still need to get to the complier. So, originally, LDFLAGS that needed to be passed into linking, weren't being passed in at all because I just assumed there was an error with doing it that way. So, be sure you're passing your LDFLAGS that yocto gives you into gcc.
I'm building GCC 8.3.0 for Windows 10, using msys, and the build fails with the following error:
gcc -c -DHAVE_CONFIG_H -g -I. -I../../source/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE ../../source/libiberty/pex-win32.c -o pex-win32.o
In file included from ../../source/libiberty/pex-common.h:25,
from ../../source/libiberty/pex-win32.c:21:
c:\software-development\prebuilt\mingw32\include\alloca.h: In function 'win32_spawn':
../../source/libiberty/../include/libiberty.h:722:20: error: inlining failed in call to always_inline '__builtin_alloca': function not considered for inlining
# define alloca(x) __builtin_alloca(x)
^~~~~~~~~~~~~~~~
In file included from c:\software-development\prebuilt\mingw32\include\stdlib.h:499,
from c:\software-development\prebuilt\mingw32\include\objbase.h:12,
from c:\software-development\prebuilt\mingw32\include\ole2.h:9,
from c:\software-development\prebuilt\mingw32\include\windows.h:100,
from ../../source/libiberty/pex-win32.c:23:
c:\software-development\prebuilt\mingw32\include\alloca.h:62:48: note: called from here
__CRT_ALIAS void *alloca( size_t __n ){ return __builtin_alloca( __n ); }
Is there a sensible way to fix this error in configuration, or failing, this, some way to patch or work around this issue?
Here is my current configuration, ran from a batch file:
--prefix=/c/software-development/gcc-8.3.0/install-x86_64-w64-mingw32 \
--build=x86_64-w64-mingw32 \
--enable-shared \
--enable-static \
--enable-bootstrap \
--enable-languages=c,c++,lto
The same error occurred when building gcc 8.2.0, and with the build guessed. I'm using GNU's MinGW 8.2.0 to build.
Try swapping everywhere in the libiberty.h file "__builtin_alloca" on "C_alloca". Replacement in one place. In preprocessor commands. It helped me.
I am working on a small project of mine on Digilent Atlys and after all of the standard generating the netlist and bitstream, and exporting to SDK, I happen to get a weird error which states that the xil_cache.h is not present anywhere (even though it is there).
I need to mention that if I don't add an interrupt controller and a timer it works, but I really do need them.
Has anyone encountered this error before?
Error Message:
08:24:21 **** Build of configuration Debug for project hiworld ****
make all
'Building file: ../src/helloworld.c'
'Invoking: MicroBlaze gcc compiler'
mb-gcc -Wall -O0 -g3 -c -fmessage-length=0 -I../../hiworld_bsp/microblaze_0/include -mlittle-endian -mxl-barrel-shift -mxl-pattern-compare -mcpu=v8.50.c -mno-xl-soft-mul -Wl,--no-relax -ffunction-sections -fdata-sections -MMD -MP -MF"src/helloworld.d" -MT"src/helloworld.d" -o "src/helloworld.o" "../src/helloworld.c"
'Finished building: ../src/helloworld.c'
' '
'Building file: ../src/platform.c'
'Invoking: MicroBlaze gcc compiler'
mb-gcc -Wall -O0 -g3 -c -fmessage-length=0 -I../../hiworld_bsp/microblaze_0/include -mlittle-endian -mxl-barrel-shift -mxl-pattern-compare -mcpu=v8.50.c -mno-xl-soft-mul -Wl,--no-relax -ffunction-sections -fdata-sections -MMD -MP -MF"src/platform.d" -MT"src/platform.d" -o "src/platform.o" "../src/platform.c"
../src/platform.c:43:23: fatal error: xil_cache.h: No such file or directory
compilation terminated.
make: *** [src/platform.o] Error 1
08:24:21 Build Finished (took 734ms)
Try after setting below environmental variables:
XILINX = C:\Xilinx\14.5\ISE_DS
XILINX_EDK = C:\Xilinx\14.5\ISE_DS\EDK\bin\nt64
this is suggested in the Xilinx forum and seems to solve the problem.
A user writes:
"Magic :-)
I created a batch file to launch it, as from what I know the path variables persit within that batch file
I set it to
set path=""
XILINX = C:\Xilinx\14.5\ISE_DS
XILINX_EDK = C:\Xilinx\14.5\ISE_DS\EDK\bin\nt64
C:\Xilinx\14.5\ISE_DS\EDK\bin\nt64\xsdk.exe
Interesting the shortcut to the SDK first contains a link to settings64.bat which I assumed set all these variables correctly, but it looks like it doesnt get them right!
I have to admit its been a trek just getting this far as the documentation is a bit blurry."
Here you can find the page.
When attempting to compile GNU GCC 5.3.0 I encounter the following error when it tries to build libjavamath.la.
/bin/bash ../../../libtool --tag=CC --mode=link /home/borish/Downloads/gcc-build/./gcc/xgcc -B/home/borish/Downloads/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Iyes/include -g -O2 -module -version-info 0:0:0 -no-undefined -Lyes/lib -lgmp -avoid-version -o libjavamath.la -rpath /usr/local/lib/../lib64/gcj-5.3.0-16 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo
../../../libtool: line 5209: cd: yes/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `yes/lib'
Makefile:403: recipe for target 'libjavamath.la' failed
This is on a Debian 8.4 system with GCC 4.9.2-10 installed. I believe I have satisfied all of the prerequisites, and Google wasn't been much help.
Any thoughts?
Update:
I used the following for running the configuration script:
../gcc-5.3.0/configure --disable-multilib --with-mpc --with-isl --with-mpfr --with-gmp
It sounds like you didn't run "configure" correctly. For example:
https://software.ecmwf.int/issues/browse/SUP-676
OK, I see a problem already, the "--with-jasper" option must point the
to the prefix of the "jasper" installation, for example
$./configure --with-jasper=/usr/local/jasper --with-png-support.
Otherwise the value "yes" is set as prefix..
For example, if you look here:
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
you'll see that a flag like ‘--with-headers=directory’ REQUIRES YOU TO ENTER A DIRECTORY PATH. I suspect the same thing is happening with your "-with-mpc" etc.
SUGGESTION: clean your build directory, and (carefully!) re-run ./configure.
The culprit appears to be the --with-gmp, --with-mpc and --with-mpfr switches when initiating the configure script. I suspect since libgmp is a prerequisite for libmpc and libmpfr, a bug feature in the configure script will include the offending -I and -L directives. Inclusion of any of them will result in the following in the root Makefile
HOST_GMPLIBS = -Lyes/lib -lmpc -lmpfr -lgmp
HOST_GMPINC = -Iyes/include
I haven't confirmed this to be the case in any of the other Makefiles, but I suspect something similar is going on elsewhere which is what I ran into when it attempted to building libjavamath.la.
The work around is to omit those switches from the configure invocation. They should be included in any event since the configure script will fail if they aren't present on the host.
I was using the options:
-O3
-march=armv7-a
-mtune=cortex-a8
-ftree-vectorize
-mfloat-abi=softfp
-fsigned-char
-Wall
-save-temps
for cross compiling for arm-v7 (32 bit) using ArmLinuxToolChain.
What is the equivalent compiler options for gcc-linaro-aarch64-linux-gnu-4.8-2014.04_linux to build for armv8? I tried using those same options with -march=armv8-a
-mtune=cortex-a53 and got:
aarch64-linux-gnu-g++: error: unrecognized command line option '-mfloat-abi=softfp'
The GCC options beginning with -m are machine-dependent options, so the availability of -m* options varies between targets. This is one such case. There is no soft float ABI defined for Aarch64, so GCC does not provide the ARM-specific -mfloat-abi option.
If you simply remove -mfloat-abi=softfp then your problem should be solved.
I would suggest you investigate whether you need -save-temps, which is normally only used for debugging or reporting compiler problems.