search

FluidSynth / fluidsynth

Software synthesizer based on the SoundFont 2 specifications
https://www.fluidsynth.org
GNU Lesser General Public License v2.1
1.84k stars 255 forks source link

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

Closed 5schatten closed 5 years ago

5schatten commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 15664c1a9055334b6845a8780051e8f49f4b2f7a and try again.

5schatten commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

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

derselbst commented 5 years ago

build failed complaining that it cannot execute make_table binary.

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

5schatten commented 5 years ago

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 https://github.com/FluidSynth/fluidsynth/commit/15664c1a9055334b6845a8780051e8f49f4b2f7a solved the problem for me & RPi builds work fine.