Menu
▾
▴
#3972 Can't install sdcc from current trunk
closed-fixed
Build
5
2026-04-08
2026-04-03
No
I cannot install sdcc from current trunk ("make install" on Debian GNU/Linux testing), the installation of the linkers fails:
/usr/bin/install -c ../../bin/sdas6808 /usr/local/bin/`echo sdas6808|sed 's,x,x,'`
strip /usr/local/bin/`echo sdas6808|sed 's,x,x,'`
strip: /usr/local/bin/sdas6808:1: Unexpected character `\177' in asxxxx .rel file
strip: /usr/local/bin/sdas6808: file format not recognized
make[1]: *** [Makefile:77: install] Fehler 1
make[1]: Verzeichnis „/home/philipp/sdcc-trunk/sdcc/sdas/as6808“ wird verlassen
make[1]: Verzeichnis „/home/philipp/sdcc-trunk/sdcc/sdas/as6500“ wird betreten
/usr/bin/install -c -d /usr/local/bin
/usr/bin/install -c ../../bin/sdas6500 /usr/local/bin/`echo sdas6500|sed 's,x,x,'`
strip /usr/local/bin/`echo sdas6500|sed 's,x,x,'`
strip: /usr/local/bin/sdas6500:1: Unexpected character `\177' in asxxxx .rel file
[…]
strip: /usr/local/bin/sdld: file format not recognized
make[1]: *** [Makefile:92: install] Fehler 1
make[1]: Verzeichnis „/home/philipp/sdcc-trunk/sdcc/sdas/linksrc“ wird verlassen
make[1]: Verzeichnis „/home/philipp/sdcc-trunk/sdcc/support/scripts“ wird betreten
cp ./as2gbmap.py ../../bin/as2gbmap && chmod +x ../../bin/as2gbmap
/usr/bin/install -c -d /usr/local/bin
/usr/bin/install -c ../../bin/as2gbmap /usr/local/bin/`echo as2gbmap|sed 's,x,x,'`
make[1]: Verzeichnis „/home/philipp/sdcc-trunk/sdcc/support/scripts“ wird verlassen
Related
Looks like my binutils update broke this in a quit4 bad way that can also affect "make install" for programs other than sdcc. It looks like SDCC "make install" installs some binutils in /usr/local/bin without the correct sd prefix. This means that a user then might have e.g. a "strip" program in the path that has no support for the host architecture, just support for SDCC targest. This "strip" program will fail with an error message when used on a host binary, and that is apparently what happens during further stages of the SDCC install.
This should be fixed in [r16451].
Related
Commit: [r16451]
While the bug should be fixed in trunk now, unfortunately, a system affected by it will still need some manual fix, as posted on the sdcc-user list. I'll repeat it here in case anyone not on the list sees this bug report:
If you did build and "make install" sdcc (from trunk or source snapshots tarball) between the beginning of March, and today, this issue most likely affects you.
During my work on merging current upstream binutils into thr SDCC fork, I introduced a bug (https://sourceforge.net/p/sdcc/bugs/3972/). The bug resulted in "make install" installing some executables into /usr/local/bin that did not have the sd prefix the binaries from the SDCC binutils fork should have.
This resulted in some executables, in particular addr2line, readelf, strip, size, strings being installed in /usr/local, i.e. in the user's path that did not support the host binaries (sine they were compiled with support for SDCC targest only).
When the user attempted to e.g. do a "strip" of a host binary, /usr/local/bin/strip could be in the path and be used instead of the correct executable. Then, instead of the intended strip action on the host binary, the user would just get an error message "Unexpected character `\177' in asxxxx .rel file"
If you are affected by the issue, you will notice executables addr2line, readelf, strip, size, strings in /usr/local/bin with the same or similar creation timestamp as /usr/local/bin/sdcc. In tha case, please:
Philipp