sparc64: xnec2c fails to link with "relocation truncated to fit" errors

[KJ7LNW]

When building the Debian sparc64 package we get the following errors. I'm not sure how to fix this so if someone has a sparc64 system to test on then reply to this issue and maybe we can troubleshoot.

Maybe using -fPIC instead of -fpie will fix it, but i don't have a way to test. I'm guessing something like LDFLAGS=-fPIC or CFLAGS=-fPIC could fix the problem. If there is a solution then I would like to see a patch to configure.ac to detect when the flag is needed.

References:

• https://buildd.debian.org/status/package.php?p=xnec2c
• https://stackoverflow.com/a/10486230/14055985
• https://lists.debian.org/debian-sparc/2014/07/msg00037.html
• https://sourceforge.net/p/cdesktopenv/tickets/92/

Here is a snippet below, or the whole log is here:

/usr/bin/ld: warning: xnec2c has a LOAD segment with RWX permissions
xnec2c-resources.o: in function `xnec2c_get_resource':
./src/xnec2c-resources.c:51279:(.text+0x10): relocation truncated to fit: R_SPARC_GOT13 against `static_resource'
xnec2c-resources.o: in function `xnec2cresource_constructor':
./src/xnec2c-resources.c:51458:(.text.startup+0x10): relocation truncated to fit: R_SPARC_GOT13 against `static_resource'
xnec2c-resources.o: in function `xnec2cresource_destructor':
./src/xnec2c-resources.c:51463:(.text.exit+0x10): relocation truncated to fit: R_SPARC_GOT13 against `static_resource'
main.o: in function `opt_start_optimizer_thread':
./src/main.c:94:(.text+0x68): relocation truncated to fit: R_SPARC_GOT13 against symbol `main_window_builder' defined in .bss section in shared.o
main.o: in function `sig_handler':
./src/main.c:724:(.text+0x18c): relocation truncated to fit: R_SPARC_GOT13 against symbol `FORKED' defined in .bss section in shared.o
./src/main.c:725:(.text+0x1b0): relocation truncated to fit: R_SPARC_GOT13 against symbol `num_child_procs' defined in .bss section in shared.o
./src/main.c:725:(.text+0x1c4): relocation truncated to fit: R_SPARC_GOT13 against symbol `forked_proc_data' defined in .bss section in shared.o
./src/main.c:731:(.text+0x1fc): relocation truncated to fit: R_SPARC_GOT13 against symbol `input_fp' defined in .bss section in shared.o
./src/main.c:724:(.text+0x244): relocation truncated to fit: R_SPARC_GOT13 against symbol `FORKED' defined in .bss section in shared.o
./src/main.c:701:(.text+0x294): relocation truncated to fit: R_SPARC_GOT13 against symbol `FORKED' defined in .bss section in shared.o
./src/main.c:708:(.text+0x2a8): additional relocation overflows omitted from the output

[ndim]

Why is xnec2c's src/Makefile.am defining -fpie at all? That looks suspiciously like something very much machine specific, so the person compiling for that specific machine should define that themselves, and I would expect package build scripts to come up with some very machine specific flags.

Perhaps libtool might have interesting defaults there, but I would not bet on it.

It might be helpful to arrange the compile and link flags in xnec2c's src/Makefile.am in a more common way so that the common Debian build scripts work as they are designed to.

[KJ7LNW]

Why is xnec2c's src/Makefile.am defining -fpie at all?

Not sure why, it dates back to at least 2015 v3.3 in commit 6a382ade8497ee1c35686e8aaefe77149c744dd5 from a .tar.gz import when old versions were plugged into git for historical reference.

A bit of history: Neoklis always released .tar.gz's by version, there wasn't ever a VCS. When he asked me to maintain xnec2c I imported all the .tar.gz's that I could find, and tagged them by version for posterity. New changes to xnec2c (starting onward from about v4.2) were rebased onto those tar.gz imports which ultimately became the repo on github that you see now.

It might be helpful to arrange the compile and link flags in xnec2c's src/Makefile.am in a more common way so that the common Debian build scripts work as they are designed to.

I'm open to your suggestions for best practices here so it compiles on as many architectures and OS's as possible.

[ndim]

Until we determine why there is a -fpie at all, we could just add an AC_LINK_IFELSE check with -fpie in configure.ac, and only add -fpie to the _CFLAGS if that compile+link succeeds. That could prevent -fpie from being used on sparc64, which would probably make it build on sparc64 - and hopefully also still run.

[ndim]

When https://github.com/KJ7LNW/xnec2c/pull/17 lands, we will have a test program with glib-compile-resource undergo AC_LINK_IFELSE, which will reference the static_resources symbol.

That will be without -fpie by default, so we will see whether the sparc64 relocation problem is more general, or if it just happens with -fpie.

We could also speculatively repeat that AC_LINK_IFELSE with -fpie to see if that makes a difference, and adapt accordingly once we have checked whether the first such build has failed or succeeded on sparc64.

[KJ7LNW]

Awesome. I'll poke the debian maintainer for a new build when this is ready and see if their build robot still has a sparc problem.

[Hibby]

Hello! Debian maintainer here - I noticed this as I was looking at the repo today and that 4.4.14 it's still failing to build on sparc64 - https://buildd.debian.org/status/fetch.php?pkg=xnec2c&arch=sparc64&ver=1:4.4.14-1&stamp=1713031587&raw=0

If there's things that need tested specifically, give me a shout - we have architecture specific boxes in the project I can use whenver to test ports to fix build issues, and I can speak to the porter team specifically for support too if need be!

[KJ7LNW]

Hi @Hibby, thanks for writing!

It looks like -fpie needs to be replaced with -fPIC and detected in configure.ac but this is only speculation I would need a way to test. Can someone on the sparc64 team give that a try, or maybe they've seen this specific build error and know a fix? If they can produce a patch against configure.ac that fixes the problem then that would be great, too.

Alternatively, would it be possible for me to get an SSH login to a sparc64 system so I can try a few things with linker flags? I probably only need user access if the necessary -dev packages are installed.

-Eric

[Hibby]

Getting access to our porterboxes is quite bureaucratic - https://dsa.debian.org/doc/guest-account/. You'd be able to set up a crossbuild chroot using sbuild & qemu akin to https://wiki.debian.org/sbuild#Cross_compiling

The mention of -fpie catches my eye - I have build hardening enabled, which is possibly clearing your flags and adding the flag for PIE amongst some others - https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2Fg.2B-.2B-_-fPIE_-pie.29

I tried to log in to a box to try a build without those flags but, of course, there was a python dependency error! I'll try a build without any hardening flags when that's back to working to at least get us to a state of working build on the architecture. Failing that I'll set up my own cross build chroot and have a bash at some stuff - I'm travelling today so it'll need to wait until I'm static!

[KJ7LNW]

Hi @Hibby,

I was able to get a sparc64 virtual machine running and can confirm that -fPIC fixes it:

root@debian:~/xnec2c# file src/xnec2c
src/xnec2c: ELF 64-bit MSB pie executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux.so.2

We will do a new release soon and have you test your build environment directly:

diff --git a/src/Makefile.am b/src/Makefile.am
index 61f72e9..8f87429 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -59,7 +59,7 @@ xnec2c_CFLAGS   += -std=gnu11
 xnec2c_CFLAGS   += -O2 -g
 xnec2c_CFLAGS   += -Wformat
 xnec2c_CFLAGS   += -Werror=format-security
-xnec2c_CFLAGS   += -fpie
+xnec2c_CFLAGS   += -fPIC
 xnec2c_CFLAGS   += -Wno-overlength-strings
 xnec2c_CFLAGS   += -DGTK_DISABLE_SINGLE_INCLUDES
 xnec2c_CFLAGS   += -DGDK_DISABLE_DEPRECATED

[KJ7LNW]

Hello @Hibby,

We just pushed to release of 4.4.16, so please give it a try and see if it builds on sparc64. If you notice any other issues (or Lintian issues) that should be solved then please let me know.

I will leave this ticket open pending your confirmation of successful build. Thanks for help!

• Eric