Riscv Compilation fails.

[VizorKit]

In file included from ../../.././riscv-gcc/libgcc/soft-fp/adddf3.c:31:
../../.././riscv-gcc/libgcc/soft-fp/soft-fp.h:42:11: fatal error: ./sfp-machine.h: Invalid argument
   42 | # include "sfp-machine.h"
      |           ^~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [../../.././riscv-gcc/libgcc/static-object.mk:17: adddf3.o] Error 1
make[3]: Leaving directory '/home/chris/riscv-gnu-toolchain/build-gcc-newlib-stage2/riscv32-unknown-elf/libgcc'
make[2]: *** [Makefile:12063: all-target-libgcc] Error 2
make[2]: Leaving directory '/home/chris/riscv-gnu-toolchain/build-gcc-newlib-stage2'
make[1]: *** [Makefile:967: all] Error 2
make[1]: Leaving directory '/home/chris/riscv-gnu-toolchain/build-gcc-newlib-stage2'
make: *** [Makefile:537: stamps/build-gcc-newlib-stage2] Error 2

I used ./configure --prefix=/opt/riscv --with-arch=rv32imac --with-abi=ilp32 I am running make for newlib. I don't really have that requirement if this is a bug specifically with newlib.

For the arguments with building, is this the correct arch and abi for the FE310-G002 cpu from SiFive? Could I use with no arch and abi specification to get the 64 bit and compile with any arch and abi?

I am on Windows 10, using MYSYS2, a mingw32 shell to compile.

Edit I tried with ./configure --prefix=/opt/riscv and make linux same issue.

In file included from ../../.././riscv-gcc/libgcc/soft-fp/addtf3.c:31:
../../.././riscv-gcc/libgcc/soft-fp/soft-fp.h:42:11: fatal error: ./sfp-machine.h: Invalid argument
   42 | # include "sfp-machine.h"
      |           ^~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [../../.././riscv-gcc/libgcc/static-object.mk:17: addtf3.o] Error 1
make[2]: Leaving directory '/home/chris/riscv-gnu-toolchain/build-gcc-linux-stage1/riscv64-unknown-linux-gnu/libgcc'
make[1]: *** [Makefile:11701: all-target-libgcc] Error 2
make[1]: Leaving directory '/home/chris/riscv-gnu-toolchain/build-gcc-linux-stage1'
make: *** [Makefile:276: stamps/build-gcc-linux-stage1] Error 2

[jim-wilson]

There should be a symbolic link in the build-gcc-newlib-stage2/riscv32-unknown-elf/libgcc dir that points at the sfp-machine.h file in the riscv-gcc/libgcc/config/riscv dir. Does this link exist? Is the link pointing at the right file? Can you view the symlink and get the right file contents?

We actually build our MS Windows binaries on a linux machine. This is easier than building them on a MS Windows machine. But builds on windows should work. I'd suspect something funny about this symlink.

The compiler will support any reasonable arch/abi combination. The tricky part is that you need the libraries built for every arch/abi combination that you want to use, otherwise you won't be able to link with the C library which most people will need. You can enable that at configure time by using --enable-multilib, which builds a preset list of arch/abi combinations. It is a reasonable list, but doesn't include all possibilities as there are too many combinations. The SiFive toolchains are build with no arch/abi option, and --enable-multilib. We also expanded the list of arch/abi combinations.

[VizorKit]

It looks like it is there.

-rw-r--r-- 1 chris None 40167 Jun 22 01:10 Makefile
lrwxrwxrwx 1 chris None    46 Jun 22 01:11 md-unwind-support.h -> ../../.././riscv-gcc/libgcc/config/no-unwind.h
-rw-r--r-- 1 chris None     4 Jun 22 01:10 multilib.out
lrwxrwxrwx 1 chris None    54 Jun 22 01:11 sfp-machine.h -> ../../.././riscv-gcc/libgcc/config/riscv/sfp-machine.h
-rw-r--r-- 1 chris None    10 Jun 22 01:10 stamp-h
lrwxrwxrwx 1 chris None    44 Jun 22 01:11 unwind.h -> ../../.././riscv-gcc/libgcc/unwind-generic.h

I cat'd out the file. Definitely looks right.

/* Software floating-point machine description for RISC-V.

   Copyright (C) 2016-2020 Free Software Foundation, Inc.

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.

You should have received a copy of the GNU General Public License and
a copy of the GCC Runtime Library Exception along with this program;
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
<http://www.gnu.org/licenses/>.  */

#if __riscv_xlen == 32

#define _FP_W_TYPE_SIZE         32
#define _FP_W_TYPE              unsigned long
#define _FP_WS_TYPE             signed long
#define _FP_I_TYPE              long

#define _FP_MUL_MEAT_S(R,X,Y)                           \
  _FP_MUL_MEAT_1_wide(_FP_WFRACBITS_S,R,X,Y,umul_ppmm)
#define _FP_MUL_MEAT_D(R,X,Y)                           \
  _FP_MUL_MEAT_2_wide(_FP_WFRACBITS_D,R,X,Y,umul_ppmm)
#define _FP_MUL_MEAT_Q(R,X,Y)                           \
  _FP_MUL_MEAT_4_wide(_FP_WFRACBITS_Q,R,X,Y,umul_ppmm)

#define _FP_DIV_MEAT_S(R,X,Y)   _FP_DIV_MEAT_1_udiv_norm(S,R,X,Y)
#define _FP_DIV_MEAT_D(R,X,Y)   _FP_DIV_MEAT_2_udiv(D,R,X,Y)
#define _FP_DIV_MEAT_Q(R,X,Y)   _FP_DIV_MEAT_4_udiv(Q,R,X,Y)

#define _FP_NANFRAC_S           _FP_QNANBIT_S
#define _FP_NANFRAC_D           _FP_QNANBIT_D, 0
#define _FP_NANFRAC_Q           _FP_QNANBIT_Q, 0, 0, 0

#else

#define _FP_W_TYPE_SIZE         64
#define _FP_W_TYPE              unsigned long long
#define _FP_WS_TYPE             signed long long
#define _FP_I_TYPE              long long

#define _FP_MUL_MEAT_S(R,X,Y)                                   \
  _FP_MUL_MEAT_1_imm(_FP_WFRACBITS_S,R,X,Y)
#define _FP_MUL_MEAT_D(R,X,Y)                                   \
  _FP_MUL_MEAT_1_wide(_FP_WFRACBITS_D,R,X,Y,umul_ppmm)
#define _FP_MUL_MEAT_Q(R,X,Y)                                   \
  _FP_MUL_MEAT_2_wide_3mul(_FP_WFRACBITS_Q,R,X,Y,umul_ppmm)

#define _FP_DIV_MEAT_S(R,X,Y)   _FP_DIV_MEAT_1_imm(S,R,X,Y,_FP_DIV_HELP_imm)
#define _FP_DIV_MEAT_D(R,X,Y)   _FP_DIV_MEAT_1_udiv_norm(D,R,X,Y)
#define _FP_DIV_MEAT_Q(R,X,Y)   _FP_DIV_MEAT_2_udiv(Q,R,X,Y)

#define _FP_NANFRAC_S           _FP_QNANBIT_S
#define _FP_NANFRAC_D           _FP_QNANBIT_D
#define _FP_NANFRAC_Q           _FP_QNANBIT_Q, 0

#endif

#if __riscv_xlen == 64
typedef int TItype __attribute__ ((mode (TI)));
typedef unsigned int UTItype __attribute__ ((mode (TI)));
#define TI_BITS (__CHAR_BIT__ * (int)sizeof(TItype))
#endif

/* The type of the result of a floating point comparison.  This must
   match __libgcc_cmp_return__ in GCC for the target.  */
typedef int __gcc_CMPtype __attribute__ ((mode (__libgcc_cmp_return__)));
#define CMPtype __gcc_CMPtype

#define _FP_NANSIGN_S           0
#define _FP_NANSIGN_D           0
#define _FP_NANSIGN_Q           0

#define _FP_KEEPNANFRACP 0
#define _FP_QNANNEGATEDP 0

#define _FP_CHOOSENAN(fs, wc, R, X, Y, OP)      \
  do {                                          \
    R##_s = _FP_NANSIGN_##fs;                   \
    _FP_FRAC_SET_##wc(R,_FP_NANFRAC_##fs);      \
    R##_c = FP_CLS_NAN;                         \
  } while (0)

#define _FP_DECL_EX             int _frm __attribute__ ((unused));
#define FP_ROUNDMODE            _frm

#define FP_RND_NEAREST          0x0
#define FP_RND_ZERO             0x1
#define FP_RND_PINF             0x3
#define FP_RND_MINF             0x2

#define FP_EX_INVALID           0x10
#define FP_EX_OVERFLOW          0x04
#define FP_EX_UNDERFLOW         0x02
#define FP_EX_DIVZERO           0x08
#define FP_EX_INEXACT           0x01

#define _FP_TININESS_AFTER_ROUNDING 1

#ifdef __riscv_flen
#define FP_INIT_ROUNDMODE                       \
do {                                            \
  __asm__ volatile ("frrm %0" : "=r" (_frm));   \
} while (0)

#define FP_HANDLE_EXCEPTIONS                                    \
do {                                                            \
  if (__builtin_expect (_fex, 0))                               \
    __asm__ volatile ("csrs fflags, %0" : : "rK" (_fex));       \
} while (0)
#else
#define FP_INIT_ROUNDMODE       _frm = FP_RND_NEAREST
#endif

#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN    4321

#define __BYTE_ORDER __LITTLE_ENDIAN

/* Define ALIASNAME as a strong alias for NAME.  */
# define strong_alias(name, aliasname) _strong_alias(name, aliasname)
# define _strong_alias(name, aliasname) \
  extern __typeof (name) aliasname __attribute__ ((alias (#name)));

[VizorKit]

Is the recommendation then to build on linux instead of windows?

Let me try the 64 bit shell before I give up.

[jim-wilson]

Build on linux if you can. Building on windows should work in theory, but we don't test it. My dual-boot machine was in linux all day today. I might have a chance to try a windows build tomorrow. There are pre-built toolchains for windows that you can try. The SiFive website has the SiFive toolchains and some third party ones like Liviu Ionescu's GNU MCU Eclipse. See https://www.sifive.com/boards and scroll down past the boards.

[VizorKit]

I was following this guide per se. I changed a few things. Namely, i needed to also install flex, and not do any of the todo deletion things

https://www.emdalo.com/posts/risc-v-gnu-compiler-toolchain-howto-compile-on-windows/

I have wiped everything, and recloned. Trying that.

[VizorKit]

I completely uninstalled MYSYS2 and started from scratch.

msys part

1. I went to this site, https://www.msys2.org/ downloaded and installed msys2. The only difference is that it is not msys32, it's msys64.
2. I followed their steps to update the package database with pacman -Syu. I got an error, that is being tracked here. Could be causing the issues, I didn't pay much attention to it if it was there when I started this. https://github.com/msys2/MSYS2-packages/issues/2021
3. I closed the window after the error, and then ran pacman -Su in MSYS2 terminal. I got the same error. I think this is most likely the cause of the problem. I went ahead and followed the fix mentioned there, so.
4. Download the tar file from Biswa96's workaround. Followed the steps there.
5. repeated Step 3, since i now had an updated filesystem.
6. Installed everything needed for risc. pacman -S mingw-w64-i686-toolchain selecting default. and then pacman -S autoconf bison diffutils make tar texinfo git flex

   riscv part

7. Opened a mingw32 terminal.
8. ran git clone --recursive https://github.com/riscv/riscv-gnu-toolchain
9. which gcc to check it was mingw32.
10. gcc -v it was version 10.x something or other.
11. Added /opt/riscv/bin to .bashrc for the mingw32 terminal, ran source ~/.bashrc.
12. Decided to just install the whole enchilada for newlib.
13. ran ./configure --prefix=/opt/riscv
14. ran make.
15. went on vacation.
16. And now we are here. I'll post the update here. when done.

[VizorKit]

That's a real bummer. Definitely made it much farther this time.

It took almost all day.

  CXX    xml-builtin.o
  CXX    xml-support.o
  CXX    xml-syscall.o
  CXX    xml-tdesc.o
  GEN    init.c
  CXX    init.o
  CXXLD  gdb.exe
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.1.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.1.0/../../../../lib/libncursesw.a(lib_termcap.o):(.bss+0x4): multiple definition of `UP'; ../readline/readline/libreadline.a(terminal.o):C:/msys64/home/chris/riscv-gnu-toolchain/riscv-gdb/readline/readline/terminal.c:779: first defined here
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.1.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.1.0/../../../../lib/libncursesw.a(lib_termcap.o):(.bss+0x0): multiple definition of `BC'; ../readline/readline/libreadline.a(terminal.o):terminal.c:(.bss+0x58): first defined here
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.1.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.1.0/../../../../lib/libncursesw.a(lib_tputs.o):(.bss+0x6): multiple definition of `PC'; ../readline/readline/libreadline.a(terminal.o):terminal.c:(.bss+0x5c): first defined here
collect2.exe: error: ld returned 1 exit status
make[3]: *** [Makefile:1908: gdb.exe] Error 1
make[3]: Leaving directory '/home/chris/riscv-gnu-toolchain/build-gdb-newlib/gdb'
make[2]: *** [Makefile:9571: all-gdb] Error 2
make[2]: Leaving directory '/home/chris/riscv-gnu-toolchain/build-gdb-newlib'
make[1]: *** [Makefile:859: all] Error 2
make[1]: Leaving directory '/home/chris/riscv-gnu-toolchain/build-gdb-newlib'
make: *** [Makefile:418: stamps/build-gdb-newlib] Error 2

The pseudo guide I was following mentioned doing this above, and it does seem related that it appears to be building in the newlib directory.

@jim-wilson What are the bear minimum ./configure and make commands I would need to build for my core without newlib? It's 32imac ilp32.

Is it ./configure --prefix=/opt/riscv --with-arch=rv64imac --with-abi=ip64 and make linux I should be able to use riscv64-none-elf-gcc -march=rv32imac -mabi=ip32 ... correct?

[jim-wilson]

I see that msys2 can be 32-bit or 64-bit, and mingw can be 32-bit or 64-bit, so there are four possible build environments here, and I'm not sure exactly which one you have. I tried 32-bit msys2 with 32-bit mingw as you mentioned a 32-bit environment at the start.

I ran into problems with git submodule update, getting odd errors about the mingw library being loaded at two different addresses. I tried an msys2 update and ran into problems, which have already been documented above. I ignored the msys2 update errors since it is only the filesystem package that has a problem. I worked around the git errors by updating submodules one at a time.

I ran into one problem with the build linking gdb. The problem here is that msys2 is using gcc 10, and gcc 10 is the first gcc version to make -fno-common the default. This requires source code changes for some packages that are relying on global variables being made common by default. In this case, the issue is that riscv-gdb/readline/readline/terminal.c has a variable definition that duplicates one in libncurses.a. That works with gcc-9 but not gcc-10. So one of these two packages will have to be fixed to avoid the conflict. I don't see any obvious upstream change to gdb for this, so maybe it is libncurses that needs the fix. Anyways, the trivial solution for us is to hack readline/readline/terminal.c to add "#define NEED_EXTERN_PC" somewhere near the top and rebuild. With that hack, my build completed.

The earlier sfp-machine.h error could have been a spurious failure.

[jim-wilson]

You can't easily build the linux target on a windows machine, as both the linux kernel and glibc require a case sensitive filesystem, and the windows filesystems are case-insensitive by default. There are ways to work around this, but making a filesystem case sensitive can break windows features, so there are tradeoffs. Maybe it will work if you put all of the msys stuff on a different filesystem than the rest of the windows, and then make only the msys filesystem case-sensitive.

It shouldn't be necessary to edit any makefiles. I didn't do that. We did add a fix for a windows build issue last year, and maybe that makefile editing stuff was required before that fix.

The compiler can emit code for any reasonable combination of arch/abi regardless of how it was configured, but the precompiled libraries will only exist for the arch/abi that you configured for, which means you won't be able to link with the C library if you change arch/abi. However, you can add --enable-multilib when configuring, and the toolchain will build about 20 or so combinations of arch/abi for each library. The build will take longer and use more disk space. This isn't every possible combination of arch/abi, just a reasonable subset of them. You can see what arch/abi combinations are supported by running gcc with the --print-multi-lib option.

If you only need one arch/abi combination, then the simplest solution is to specify them using --with-arch/--with-abi when configuring. So what you did at the top is correct.

We don't support building the toolchain without newlib.

[VizorKit]

@jim-wilson that worked! However I did run into some oddities when I tried to use riscv64-unknown-elf-gcc to compile and link .c and .S files with -march=rv32imac -mabi=ilp32.

Something about the littleriscv elf format 64 incompatible with 32 bit.

Since that worked, I ran make clean, and will run through without the specific abi and arch, to get all of them. I'll definitely tarball this up somewhere and save it, boyo those build times!

[jim-wilson]

That is a multilib problem. The compiler supports any reasonable arch/abi combination, but you don't have a C library compiled for -march=rv32imac/-mabi=ilp32 so you get a link error when you try to link with the C library. You can fix that by adding --enable-multilib which will build a selection of about 20 arch/abi choices. Or by using explicit with-arch/with-abi options when configuring so that the single precompiled C library is built with the arch/abi options you want to use.

[VizorKit]

I swear I compiled with --enable-multilib. Is there a quick way to check?

I ran

riscv64-unknown-elf-as -march=rv32imac -mabi=ilp32 novectors.s -o novectors.o
riscv64-unknown-elf-gcc -march=rv32imac -mabi=ilp32 -Wall -O2 -nostdlib -nostartfiles -ffreestanding  -c notmain.c -o notmain.o

and got...

novectors.s: Assembler messages:
novectors.s: Warning: end of file not at end of a line; newline inserted
C:\msys64\opt\riscv\bin\riscv64-unknown-elf-ld.exe: novectors.o: ABI is incompatible with that of the selected emulation:
  target emulation `elf32-littleriscv' does not match `elf64-littleriscv'
C:\msys64\opt\riscv\bin\riscv64-unknown-elf-ld.exe: failed to merge target specific data of file novectors.o
C:\msys64\opt\riscv\bin\riscv64-unknown-elf-ld.exe: notmain.o: ABI is incompatible with that of the selected emulation:
  target emulation `elf32-littleriscv' does not match `elf64-littleriscv'
C:\msys64\opt\riscv\bin\riscv64-unknown-elf-ld.exe: failed to merge target specific data of file notmain.o
C:\msys64\opt\riscv\bin\riscv64-unknown-elf-ld.exe: notmain.elf(.text): relocation "_dummy+0x0 (type R_RISCV_CALL)" goes out of range
C:\msys64\opt\riscv\bin\riscv64-unknown-elf-ld.exe: notmain.o: file class ELFCLASS32 incompatible with ELFCLASS64
C:\msys64\opt\riscv\bin\riscv64-unknown-elf-ld.exe: final link failed: file in wrong format

[VizorKit]

Yea That is the filesystem. And I found a Precompiled binary for windows online Here https://gnutoolchains.com/risc-v/ Same issue with that toolchain.

output of riscv64-unknown-elf-gcc -v

$ riscv64-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\opt\riscv\bin\riscv64-unknown-elf-gcc.exe
COLLECT_LTO_WRAPPER=c:/msys64/opt/riscv/bin/../libexec/gcc/riscv64-unknown-elf/10.1.0/lto-wrapper.exe
Target: riscv64-unknown-elf
Configured with: /home/chris/riscv-gnu-toolchain/riscv-gcc/configure --target=riscv64-unknown-elf --prefix=/opt/riscv --disable-shared --disable-threads --enable-languages=c,c++ --with-system-zlib --enable-tls --with-newlib --with-sysroot=/opt/riscv/riscv64-unknown-elf --with-native-system-header-dir=/include --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --disable-tm-clone-registry --src=.././riscv-gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket 'CFLAGS_FOR_TARGET=-Os   -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os   -mcmodel=medlow'
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC)

[jim-wilson]

You show two gcc commands using -c, and then a linker error. The linker error could not have been produced by either of those gcc commands. The linker error suggests a problem with your linker command which you didn't show. Did you pass the -march and -mabi options to the linker? The R_RISCV_CALL error suggests you might have a linker script, and either there is a problem with the linker script, or you didn't compile code correctly to work with the linker script. But I don't have enough info to tell what is going on here.

As mentioned previously, running gcc with the --print-multi-lib option will show you what march/mabi options are supported by precompiled libraries.

[VizorKit]

You can mark this is closed. I will create a new "issue".

Thank you for your help!

[MichaelsChild]

Hi, has this issues been resolved since there is no link to a new problem report? I have exactly the same problem. 64 no issues compiles smoothly, 32 python issues(solved) and linking problem as mentioned above. Thanks!

[jim-wilson]

There are multiple problems reported here, and most of them are user errors. You will have to be more specific. if you built a 64-bit toolchain and 32-bit compiles aren't working, then you probably forgot to add --enable-multilib when configuring. The compiler will support all reasonable arch/abi combinations, but you won't have precompiled libraries for non-default arch/abi options unless you use --enable-multilib. Even then, you will only have a precompiled libraries for a subset of arch/abi options because there are far too many to build them all by default. So you need to be much more specific about how to exactly reproduce your problem. And it would be best if you opened a new issue for your problem.