On 2021-01-23 18:24 -0500, John Scott wrote: > Hi, > > I'm looking into the most painless way to make cross Binutils for sh-elf, but > it seems like most documentation and tools are oriented towards Linux > crossbuilds. I see there is some code in the Binutils package for recognizing > GNU triplets, but setting TARGET=sh-elf and building fails with > x86_64-linux-gnu-gcc stamps/build..o -o stamps/build. > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': > (.text+0x20): undefined reference to `main' > collect2: error: ld returned 1 exit status > make: *** [<builtin>: stamps/build.] Error 1 > > The Electronics Team seems to use various ugly hacks for their > cross-compilers. What would be the most effective strategy for tackling this? If I understand what you are trying to do it is to make a bare-metal toolchain for use in a non-OS/low-level environment? I suggest you look how this has been done for the arm-none toolchain which solves the same problem. the source packages are: binutils-arm-none-eabi gcc-arm-none-eabi libnewlib-nano libstdc++-arm-none-eabi It is possible in theory to produce arm-none binaries from the standard binutils and gcc packages, but as you say there is a lot of linux-based machinery in there and it would be intrusive to do bare-metal builds in that packaging, so the maintainers decided it made more sense to do as separate sources. The binutils packaging uses the existing binutils source but adds new packaging and thus build-runes. Just changing the target in binutils-arm-none-eabi to sh-elf appears to build the tools correctly (but calls them all the wrong things). Making a binutils-sh-unknown-elf package looks like it would be straightforward. You could paramaterise things so that it can build both flavours of bare-metal compiler. That would be more maintable in the long run. HTH Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature