[Bug]: GCC on Linux fails linking CMake-based JUCE audio plugins with binary data
danra opened this issue · comments
Detailed steps on how to reproduce the bug
GCC on Linux fails linking CMake-based JUCE audio plugins with binary data.
This appears to be due to position-independent code not being set on the binary data target, whereas it is set on the other targets, causing the linker to error out:
/usr/bin/ld: libAudioPluginData.a(BinaryData1.cpp.o): warning: relocation against `_ZN10BinaryData17originalFilenamesE' in read-only section `.text'
/usr/bin/ld: libAudioPluginData.a(BinaryData1.cpp.o): relocation R_X86_64_PC32 against symbol `_ZN10BinaryData13StarWars3_wavE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
Attached below is a minimal example based on the CMake AudioPlugin example, with a GitHub CI workflow that fails on GitHub's Ubuntu action runner.
Possible workaround (added and commented out in the minimal example): Turning on CMAKE_POSITION_INDEPENDENT_CODE yourself.
What is the expected behaviour?
The default provided targets should have non-conflicting build settings.
A rough fix would be to just add the workaround to the example. It looks like the existing CMake support is attempting to set this properly on all its targets, though, so I guess it's that support that needs to be amended to also include the binary data target.
Operating systems
Linux
What versions of the operating systems?
Ubuntu 22.04
Architectures
x86_64
Stacktrace
No response
Plug-in formats (if applicable)
No response
Plug-in host applications (DAWs) (if applicable)
No response
Testing on the develop branch
The bug is present on the develop branch
Code of Conduct
- I agree to follow the Code of Conduct
A rough fix would be to just add the workaround to the example.
I'm not sure whether we should enable PIC for all binary data targets, as sometimes these will only be linked into executable targets that don't require PIC. That said, it looks like linking a PIC staticlib into a non-PIC executable works, so perhaps this is the simplest solution.
It looks like the existing CMake support is attempting to set this properly on all its targets, though, so I guess it's that support that needs to be amended to also include the binary data target.
I'm not sure - I think we only enable PIC for plugin shared-code and wrapper targets.