Build failure on Arch Linux: "undefined section `.rt.text' referenced in expression"
Gimmeapill opened this issue · 9 comments
Hi Hermann,
I'm having a build failure as of 0.43.1r4 (build log log attached + PKGBUILD attached).
As far as I understood this could be related to zita-resampler, so I tried to disable it but no luck.
I couldn't find anything either in the official Arch Package, so here is it:
/usr/bin/ld:../src/gx_head/guitarix.lds:1: undefined section `.rt.text' referenced in expression
collect2: error: ld returned 1 exit status../src/headers/gx_resampler.h:61:7: warning: type ‘struct FixedRateResampler’ violates the C++ One Definition Rule [-Wodr]
61 | class FixedRateResampler {
| ^
../src/headers/gx_resampler.h:61:7: note: a different type is defined in another translation unit
61 | class FixedRateResampler {
| ^
../src/headers/gx_resampler.h:63:15: note: the first difference of corresponding definitions is field ‘r_up’
63 | Resampler r_up, r_down;
| ^
../src/headers/gx_resampler.h:63:15: note: a field of same name but different type is defined in another translation unit
63 | Resampler r_up, r_down;
| ^
/usr/include/zita-resampler/resampler.h:28:7: note: type ‘struct Resampler’ itself violates the C++ One Definition Rule
28 | class Resampler
| ^
../src/zita-resampler-1.1.0/zita-resampler/resampler.h:28:7: note: the incompatible type is defined here
28 | class Resampler
| ^
Please remove the --new-ladspa flag, I've recently no time to fix it, and think about to remove it from the build anyway.
Still no luck after removing anything ladspa related, although it seems to fail at a later stage:
/usr/bin/ld: src/gx_head/gui/avahi_discover.cpp.1.o: plugin needed to handle lto object
/usr/bin/ld:../src/gx_head/guitarix.lds:1: undefined section `.rt.text' referenced in expression
collect2: error: ld returned 1 exit statusWaf: Leaving directory `/build/guitarix-git/src/guitarix/trunk/build'
File "/usr/bin/waf", line 168, in
Scripting.waf_entry_point(cwd, VERSION, wafdir)
File "/lib/python3.10/site-packages/waf/waflib/Scripting.py", line 159, in waf_entry_point
run_commands()
File "/lib/python3.10/site-packages/waf/waflib/Scripting.py", line 255, in run_commands
ctx = run_command(cmd_name)
File "/lib/python3.10/site-packages/waf/waflib/Scripting.py", line 239, in run_command
ctx.execute()
File "/lib/python3.10/site-packages/waf/waflib/Scripting.py", line 582, in execute
return execute_method(self)
File "/lib/python3.10/site-packages/waf/waflib/Build.py", line 231, in execute
self.execute_build()
File "/lib/python3.10/site-packages/waf/waflib/Build.py", line 251, in execute_build
self.compile()
File "/lib/python3.10/site-packages/waf/waflib/Tools/errcheck.py", line 192, in check_compile
ret = self.orig_compile()
File "/lib/python3.10/site-packages/waf/waflib/Build.py", line 355, in compile
raise Errors.BuildError(self.producer.error)
File "/lib/python3.10/site-packages/waf/waflib/Errors.py", line 46, in init
WafError.init(self, self.format_error())Build failed
Looking at my build archive, the last version building properly was 0.43.1.r0 (so around the end of December). But there were numerous changes in Arch so this probably doesn't help much...
It may help to add --ldflags=-ffat-lto-objects, but I can't say for sure.
I'll have a depper look into it when I'm back in 2 weeks.
sorry
Didn't help either, but no worries we can survive for a while with the official package.
Thanks for your time ;-)
The -ffat-lto-objects needs to be added to the CXXFLAGS when you use -flto in the CXXFLAGS
I've implemented a check which will append -ffat-lto-objects automatically when -flto is used.
I'm afraid this is still not working (I had also tried to append it manually), but this is probably a packaging issue then.
The -flto flag is not a default on Arch Linux, so I have really no idea where it comes from:
-> Here are the Arch defaults:
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
-> The build flags from my pkgbuild:
waf configure --prefix=/usr
--optimization
--includeresampler
--includeconvolver
--enable-nls
--no-faust
--shared-lib
--lib-dev
--ldflags="${LDFLAGS}
-> The flags as reported in the build log (full log attached):
C++ flags : -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -flto -Wall -DGSEAL_ENABLE -O3 -DNDEBUG -march=k8 -mmmx -m3dnow -msse4.2 -mfpmath=sse -fomit-frame-pointer -ftree-loop-linear -fno-math-errno -fno-signed-zeros -fstrength-reduce -pipe -std=c++11
Link flags : -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto
It may work when you add --cxxflags='-flto' so that waf knows beforehand about it. I build it here by give all those flags you use over the --cxxflags switch and it works.
Other than that it is a issue within build utilities been build without plugin support. The -ffat-lto-objects is a workaround for this issue.
I'm pretty sure that otherwise you wont have any issue to build by simple waf commands (without involve pkgbuild)
The trick worked ;-)
Thanks Hermann!