strip: "Not enough room for program headers, try linking with -N" zb bei sudo

[pony1k]

Hallo!
Ich wollte mir gerade ein für meine 7490 ein Image mit dem sudo-Paket bauen. Dabei bekam ich folgendes:

mkdir -p packages/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/sudo-1.7.10p8/root/usr/bin/; cp source/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/sudo-1.7.10p8/sudo packages/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/sudo-1.7.10p8/root/usr/bin/sudo; [ "y" == "y" ] && tools/patchelf --set-interpreter /usr/lib/freetz/ld-uClibc.so.1 packages/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/sudo-1.7.10p8/root/usr/bin/sudo || true; /home/she-ra/freetz-ng/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-strip --remove-section={.comment,.note,.pdr} packages/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/sudo-1.7.10p8/root/usr/bin/sudo;
/home/she-ra/freetz-ng/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-strip: packages/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/sudo-1.7.10p8/root/usr/bin/stdoQJ7y: Not enough room for program headers, try linking with -N
/home/she-ra/freetz-ng/toolchain/build/mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-strip:packages/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/sudo-1.7.10p8/root/usr/bin/stdoQJ7y[.MIPS.abiflags]: Bad value
make: *** [make/sudo/sudo.mk:34: packages/target-mips_gcc-5.5.0_uClibc-1.0.37-nptl_kernel-3.10/sudo-1.7.10p8/root/usr/bin/sudo] Error 1

In der sudo.mk fand ich das hier

33: $($(PKG)_BINARY_TARGET_DIR): $($(PKG)_DEST_DIR)/usr/bin/%: $($(PKG)_DIR)/%
34: 	$(INSTALL_BINARY_STRIP)
35: 	chmod +s $(SUDO_BINARY_TARGET_DIR)

Anscheinend tritt der Fehler beim verkleinern der sudo-binary auf, was ja nicht essentiell notwendig ist. Deshalb habe das ersetzt durch:

$($(PKG)_BINARY_TARGET_DIR): $($(PKG)_DEST_DIR)/usr/bin/%: $($(PKG)_DIR)/%
	$(INSTALL_FILE) \
	[ "$(FREETZ_SEPARATE_AVM_UCLIBC)" == "y" ] && $(TOOLS_DIR)/patchelf --set-interpreter $(FREETZ_LIBRARY_DIR)/ld-uClibc.so.1 $@ || true
	chmod +s $(SUDO_BINARY_TARGET_DIR)

Dann gings.
Ich muss aber dazu sagen, dass ich nicht so eine richtige Ahnung habe, was ich da tue und ob das die richtige Lösung für das Problem ist. Auch weiß ich nicht, warum strip diesen Fehler produziert.

[fda77]

INSTALL_BINARY_STRIP wäre schon besser. Hast du Not enough room for program headers, try linking with -N probiert? Vielleicht geht das mit einer Option in der .mk $(PKG)_CONFIGURE_OPTIONS +=
Strippen braucht man grundsätzlich nicht, bei Geräten mit 4/8/16 MB Flash wird es aber schnell eng
Übrigens sollte sudo in Freetz mal aktualisiert werden, vor ein paar Wochen/monaten gabs da ein Sicherheitsproblem

[pony1k]

Habe in der sudo.mk

$(PKG)_CONFIGURE_PRE_CMDS += $(call PKG_PREVENT_RPATH_HARDCODING,./configure)

zu

$(PKG)_CONFIGURE_PRE_CMDS += $(call PKG_PREVENT_RPATH_HARDCODING,LDFLAGS=-N ./configure)

geändert. Bekomme aber wieder die selbe Fehlermeldung.

[fda77]

9b47913

[pony1k]

Habe

git pull
make olddefconfig
make sudo-dirclean
make tools-distclean
make

aufgerufen. Kommt aber immernoch der Fehler. Was habe ich falsch gemacht?

[fda77]

Ich weiss nicht ob du die tools selbst baust oder die vorcompilierten verwendest. Die Datei liegt jedenfalls in tools/, schau mal nach dem Datum.

[pony1k]

scheint neu zu sein:

she-ra@etheria:~/freetz-ng$ tools/patchelf --version
patchelf 0.12.20200827.8d3a16e
she-ra@etheria:~/freetz-ng$ ls -l tools/patchelf
-rwxr-xr-x 1 she-ra she-ra 3014976 Jul  1 19:17 tools/patchelf

[fda77]

Das Problem ist jetzt vermutlich dass ld zu alt ist. ld ist Teil der binutils (toolchain in freetz)

• Warum nutzt Freetz so eine alte Version?
• Es wird die gleich verwendet die AVM verwendet.
• Warum nutzt AVM so eine alte Version?
• Es wird die zu gcc "passende" verwendet
• Warum nutzt AVM so eine alte gcc Version?
• Es wird die zum kernel "passende" verwendet
• Warum nutzt AVM so eine alte Kernel Version?
• AVM nutzt closed-source Module für diverse Hardware wie Dect, Telefonie oder Wlan. Ausserdem gibt es Anpassungen für dieses PacketAccelerator-Ding. Dies auf einen aktuellen Kernel zu portieren scheint zu aufwändig.

Eine Firma die das "richtig" machen wollte würde ihre Patches upstream in den Kernel commiten und so der Community helfen statt nur die Vorteile des Kernel zu nutzen. Mit closed-source Kram ist das natürlich schwer...
Als Alternative bietet sich OpenWrt an (falls das gerät unterstützt wird), die werfen diesen ganzen Kram weg und nutzen einen normalen Kernel - Spezialhardware geht dann halt nicht. Man kann aber ganz normales Routing, conntrack usw nutzen

Ich baue später eine aktuelle binutils Version ein, dafür muss aber die Toolchain selbst gebaut werden! Ob das irgend welche preoblem geben wird, wird man sehen ^^

[fda77]

0ec514e