On Wed, Dec 9, 2020 at 7:02 AM Jakub Jelinek via Gcc-patches < gcc-patches@gcc.gnu.org> wrote:
> On Wed, Dec 09, 2020 at 03:57:51PM +0100, Matthias Klose wrote: > > On 12/9/20 3:03 PM, Simon Cook wrote: > > > When building GCC for RISC-V with the --with-multilib-generator option, > > > it may not be possible to call arch-canonicalize as an executable when > > > building on Windows. Instead directly invoke the expected python > > > interpreter for this step. > > There is nothing in the two scripts that can't be easily done in awk > or shell. > I think it would be best to rewrite those scripts in those languages. > multilib-generator is for specifying embedded elf multilibs which get complicated considering all of the arch extensions and sub-extensions that we need to support. This isn't relevant to native compilers, and hence not a compiler bootstrap issue. arch-canonicalize is just a very minor optimization to avoid redundant multilibs, and again, it is really for embedded elf multilibs, and of no practical use for native compilers, and hence not a bootstrap issue. The only problem was that we were calling it always, even if no multilibs and no python, and Kito fixed that by making it optional, only calling it if python exists. We could perhaps further improve this by only calling it when --enable-multilibs was specified. Anyways, as things currently stand, the RISC-V port has no python requirement to build a native compiler (after Kito's last fix). And only an optional need for python for embedded elf --enable-multilib build if you want to use the --enable-multilib-generator configure option, or if you want to avoid one duplicate multilib that is possible if you accidentally specify a non-canonical --with-arch target. So there is no immediate need to rewrite the scripts. Jim
