[RPi / crosscompile] The C compiler "/usr/bin/cc" is not able to compile a simple test program.

[5schatten]

FluidSynth version

2.0.3

Current behavior

Cross compile fails for RPi targets.

Expected behavior

Should compile fine like version 2.0.1 also version 2.0.3 compiles fine for Generic x86_64 builds

Steps to reproduce

Cross compile FluidSynth 2.0.3 with a recent LibreELEC toolchain.

Other information

Log file:
https://pastebin.com/wWTD85G0

This package.mk is build by the toolchain

[derselbst]

I would guess that your $CFLAGS env variable is "polluted" with the flags that your host compiler complains about. Could you post `echo $CFLAGS`? Also please post the toolchain file (just for curiosity).

[5schatten]

The thing is my "host" compiler shouldn't kick in but the cross compiler in my buildroot. But I'm not sure if it's about the flags since version 2.0.1 builds fine for Generic / RPi / Amlogic devices but 2.0.3 fails for the ARM devices.

CFLAGS:
-march=armv7ve -mtune=cortex-a7 -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -fomit-frame-pointer -Wall -pipe -Os -fPIC -DPIC

The actual flags depend on the target:
https://github.com/LibreELEC/LibreELEC.tv/blob/master/config/optimize
https://github.com/LibreELEC/LibreELEC.tv/blob/master/config/arch.arm

[derselbst]

The thing is my "host" compiler shouldn't kick in

It should, it's intended. We need the host compiler to compile a C program that generates various lookup tables. This allows to make them compile-time constant and being placed in a FlashROM, rather than generating them at runtime and putting them in RAM as we did <2.0.2.

Please apply commit 15664c1 and try again.

[5schatten]

I mean it shouldn't use the x64 gcc of my Linux Mint host but the Linaro ARM GCC in my buildroot of my toolchain. Your patch fixed the issue for my Vim so I'll do further testing with RPi builds but the issue is probably solved. 👍

[derselbst]

I mean it shouldn't use the x64 gcc of my Linux Mint host but the Linaro ARM GCC in my buildroot of my toolchain.

You don't seem to understand: The host compiler only builds the make_tables program, so that it can be executed on your x64 host during the build to generate the lookup tables.

[5schatten]

Well I really don't understand why it builds make_tables.exe for a unix (linux) target of the suffix is more likely for windows systems.

[5/52] Performing configure step for 'gentables'
-- The C compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/supervisedthinking/le90-rr/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/fluidsynth-git-2.0.3/.x86_64-libreelec-linux-gnu/src/gentables
[6/52] Performing build step for 'gentables'
[1/4] Building C object CMakeFiles/make_tables.dir/gen_conv.c.o
[2/4] Building C object CMakeFiles/make_tables.dir/make_tables.c.o
[3/4] Building C object CMakeFiles/make_tables.dir/gen_rvoice_dsp.c.o
[4/4] Linking C executable make_tables.exe

Also it should use GNU 8.2.0 located in my buildroot & not GNU 7.3.0 of my host system.

-- The C compiler identification is GNU 8.2.0
-- Check for working C compiler: /home/supervisedthinking/le90-rr/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/toolchain/bin/x86_64-libreelec-linux-gnu-gcc
-- Check for working C compiler: /home/supervisedthinking/le90-rr/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.0-devel/toolchain/bin/x86_64-libreelec-linux-gnu-gcc -- works

IMHO CMake should use something like CMAKE_FIND_ROOT_PATHto determine the root path of the buildroot and use /home/supervisedthinking/le90-rr/LibreELEC.tv/build.LibreELEC-KVIM.arm-9.0-devel/toolchain/bin/armv8a-libreelec-linux-gnueabi-gcc & not the one of my host system /usr/bin/cc

Or is it suitable to use a x86_64 tool to generate the tables for ARM too?

[derselbst]

Well I really don't understand why it builds make_tables.exe for a unix (linux) target of the suffix is more likely for windows systems.

Names don't mean anything. Trust me, readelf will tell you it's a linux binary. For background: #477 and #475

Or is it suitable to use a x86_64 tool to generate the tables for ARM too?

Yes. Think of it as a python script that generates a bunch of numbers. Just that we don't want people to install python when having to build fluidsynth.

[schnitzeltony]

I build fluidsynth cross with Openembedded - see my so called recipes at [1] (the link is WIP and will be rebased - particularly ARM-NEON patch might go). Important: make_tables (don't worry about the exe extension) is a helper tool necessary to build target fluidsynth.
In my build this is done by fluidsynth-native.bb and target fluidsynth depends on it. I had to create some patches for fluidsynth-native to avoid huge native dependencies and reduce build just to make_tables and for target fluidsynth to use native make_tables. This dance is necesarry because it is not possible to run ARM binary on my build host (unless you choose some qemu adventure...)

Hope that helps...

[1] https://github.com/schnitzeltony/meta-openembedded/tree/thud%2Bfluidsynth-2.x/meta-multimedia/recipes-multimedia/fluidsynth

[derselbst]

This dance is necesarry because it is not possible to run ARM binary on my build host

I don't quite understand. ExternalProject should make sure that cmake calls your host compiler to generate a native make_tables binary so that it can be run on your host machine. Why do you need to split this?

[schnitzeltony]

I don't quite understand. ExternalProject should make sure that cmake calls your host compiler to generate a native make_tables binary so that it can be run on your host machine. Why do you need to split this?

Am no CMake expert but build failed complaining that it cannot execute make_table binary. Seems ExternalProject does not work for me. Since this is daily business (KDE does similar at umpteen places) I did what I usually do:

• Reduce native build to what's necessary
• Adjust target build

Seems @5schatten build system is more clever - it tries to use host compiler. So maybe the 'dance' is not necessary for him.

[derselbst]

build failed complaining that it cannot execute make_table binary.

Shouldn't happen. Could you share the verbose build log on occasion?

[5schatten]

Well, it's not "my" build system, it's LibreELEC's. The system aims multiple arches & devices so it has to deal with a lot of different packages for each build. So I guess you can say it must be quite clever 👍

The commit 15664c1 solved the problem for me & RPi builds work fine.