Riscv-gnu-toolchain build error

Hi,

I am trying to build riscv-gnu-toolchain repository. I am getting this strange error when i do sudo make .

make -C build-binutils-newlib
make[1]: Entering directory ‘/mnt/c/UserData/RISCV/repositories/riscv-gnu-toolchain/build-binutils-newlib’
Makefile:527: *** missing separator. Stop.
make[1]: Leaving directory ‘/mnt/c/UserData/RISCV/repositories/riscv-gnu-toolchain/build-binutils-newlib’
Makefile:396: recipe for target ‘stamps/build-binutils-newlib’ failed
make: *** [stamps/build-binutils-newlib] Error 2

Before this the configure script worked fine. Attached the image of the console. Is there any problem with makefile ? why it says missing separator?

quick help is needed for me as i am stuck since one day here.

The error message points at line 527 of build-binutils-newlib/Makefile. So what is on line 527?

Hi JIm,

These are the statements in MakeFile from line 527 to line 530

#host and target specific makefile fragments come in here.
@target_makefile_frag@
@alphaieee_frag@
@ospace_frag@
@host_makefile_frag@

and line 396 has following statement

STAGE_TFLAGS = $(TFLAGS)

@target_makefile_frag@ is supposed to be replaced with the file specified by target_makefile_frag, which is a variable set by the configure script. In config.status you should see something like
F[“target_makefile_frag”]="/dev/null"
followed by an awk script that replaces @target_makefile_frag with the contents of the specified file, which is /dev/null in this case.

So it looks like awk is broken. GCC requires GNU awk. You haven’t mentioned what system you are trying to build on. If you are trying to build on a mac you must use gawk instead of awk. You can set the environment variable AWK to gawk to force this. You also need to use gsed instead of sed. Otherwise, I think awk should be gawk and should be working.

FWIW, in my experience it’s easier and more reliable to build the RISC-V tools using @ilg’s xPack Project docker based scripts or CT-NG:

https://xpack.github.io/riscv-none-embed-gcc/#build-details

https://crosstool-ng.github.io/

There is also sifive/freedom-tools. This has explicit support for native builds on mac and linux, and cross builds for windows hosted on linux. And downloading a pre-built binary is always an option if you don’t need to modify the sources. We have binaries for linux, mac, and windows on the sifive web site, for the SiFive toolchain and 3rd party toolchains like Liviu’s.

Hi,

I am currently using WSL1(Windows Subsystem for Linux) with Ubuntu 18.04(which uses Linux kernel). I have windows 10 machine. Here are my awk, gcc , autoconf, automake tool version on Ubuntu 18.04

GNU Awk 4.1.4, API: 1.1 (GNU MPFR 4.0.1, GNU MP 6.1.2)
Copyright © 1989, 1991-2016 Free Software Foundation.

gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
autoconf (GNU Autoconf) 2.69
automake (GNU automake) 1.15.1

My plan is to build the gcc toolchain first to create riscv64-unknown-elf-gcc to compile small c program so that it can create elf binary, and then use Spike simulator to simulate this program using Spike pk . My ultimate goal is to add some custom instruction later and simulate that instruction in Spike. So i am using the repository https://github.com/riscv/riscv-tools

Can i achieve to build riscv64-unknown-elf-gcc using xpack-dev-tool also ? currently i am using https://github.com/riscv/riscv-gnu-toolchain and was trying to build the toolchain, but stuck with this make error as mentioned earlier.

So, the error said missing separator. This make file is auto-generated by config.status right ? Is this error related to Tabs in makfile ? If i could not resolve this makefile problem can i use xpack-dev-tools as Murphy suggested ?

The toolchain builds fine with Ubuntu 18.04. I don’t know about running Ubuntu under WSL1 though. I don’t know if anyone has tried that. The only generic windows problem I know about is that it uses a case-insensitive filesystem even inside WSL1, where as linux is case-sensitive. This will break linux toolchain builds, but should not break embedded elf toolchain builds.

The configure script creates config.status, and then runs config.status to create the Makefile. This doesn’t have anything to do with tabs in makefiles. I don’t know why this is failing. I can’t suggest anything other than trying to debug it. Or trying to build a different way.

I don’t know anything about xpack.

The other way to build on Windows is to use mingw64 and msys2. This provides a posix environment with a shell, and some people have been able to build the toolchain this way. Though it may require working around a few issues.

Thanks for the reply.

I now use MSYS2 with mingw64 to build the riscv gnu toolchain. Now the make errors are gone. But i now got below errors.

plural.c:184:5: error: conflicting types for ‘libintl_gettextparse’
int __gettextparse (void);
^
/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural.y:40:25: note: expanded from macro ‘__gettextparse’

define __gettextparse PLURAL_PARSE

                    ^

/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural-exp.h:102:23: note: expanded from macro ‘PLURAL_PARSE’

define PLURAL_PARSE libintl_gettextparse

                  ^

/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural-exp.h:114:12: note: previous declaration is here
extern int PLURAL_PARSE PARAMS ((void *arg));
^
/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural-exp.h:102:23: note: expanded from macro ‘PLURAL_PARSE’

define PLURAL_PARSE libintl_gettextparse

                  ^

plural.c:1129:1: error: conflicting types for ‘libintl_gettextparse’
yyparse (void)
^
plural.c:63:25: note: expanded from macro ‘yyparse’
#define yyparse __gettextparse
^
/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural.y:40:25: note: expanded from macro ‘__gettextparse’

define __gettextparse PLURAL_PARSE

                    ^

/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural-exp.h:102:23: note: expanded from macro ‘PLURAL_PARSE’

define PLURAL_PARSE libintl_gettextparse

                  ^

/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural-exp.h:114:12: note: previous declaration is here
extern int PLURAL_PARSE PARAMS ((void *arg));
^
/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural-exp.h:102:23: note: expanded from macro ‘PLURAL_PARSE’

define PLURAL_PARSE libintl_gettextparse

                  ^

plural.c:1298:30: error: too few arguments to function call, expected 2, have 1
yychar = yylex (&yylval);
~~~~~ ^
/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural.y:69:1: note: ‘__gettextlex’ declared here
static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
^
/usr/home/hegdemur/riscv/_riscv-gnu-toolchain/riscv-binutils-gdb/intl/plural.y:178:29: error: use of undeclared identifier ‘arg’
((struct parse_args *) arg)->res = (yyvsp[0].exp);

should i use specific version of bison and gcc here ? my current bison version in msys2 is
bison (GNU Bison) 3.6.4
Written by Robert Corbett and Richard Stallman.

Copyright © 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and GCC version is

gcc.exe (Rev1, Built by MSYS2 project) 10.2.0
Copyright © 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

This is a known bug with binutils
https://sourceware.org/bugzilla/show_bug.cgi?id=22941

If the source file intl/plural.y is newer than the generated file intl/plural.c, then the makefile will run bison on plural.y, except that the very latest versions of bison don’t work with the binutils plural.y file anymore.

The workaround is to repair the damage to your source tree, i.e. undo any accidental source file changes, and then do “touch intl/plural.c” to make sure that plural.c is newer than plural.y. This will prevent make from running bison, and this build failure will not occur.

Hi

I could build the gnu toolchain in mingw… Now i am trying to build this in WSL ubuntu 20.04 version.

Since i use SPIKE simulator, i have to build the toolchain with linux binaries.

i am getting some strange errors while building riscv-gnu-toolchain on WSL ubuntu 20.04. Attached is the snapshot of build.

My installed GCC version in ubuntu is
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Copyright © 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The error is coming while building libiberty, and it is unable to find LONG_MIN definition which is defined in limits.h header file. i see that limits.h header file exists in the system.
\wsl1\Ubuntu-20.04\usr\include\limits.h

Can u help in fixing this error ?

Linux systems usually have more than one <limits.h> file. You should be using the limits.h file in the gcc install tree first, which should then include the limits.h in the glibc install tree. The second one is the one in /usr/include/limits.h. Try adding a --save-temps option to the gcc command that is failing, and look at the .i file that is produced. Check header file inclusions to make sure the right header files are being included. Also check the macros like HAVE_LIMITS_H to make sure that they are defined correctly. Maybe something went wrong during configure and HAVE_LIMITS_H isn’t defined.

All works perfectly in WSL using Ubuntu 18.04.

I imagine very few people are using 20.04 yet so there are likely to be problems using it even as the native OS.

Hi,

Ok… Do u recommend any specific version of gcc to be installed on ubuntu to build the risc-v toolchain? or the default one provided by ubuntu is fine ? is there specific requirement of riscv-gnu-toolchain that i have to build on specific gcc compiler?

The default x86 gcc is fine.

If we’re creating RISC-V programs it’s the quality of the RISC-V code generation and support of new RISC-V extensions we care about, not whether a newer x86 gcc might make the RISC-V compiler very slightly smaller or faster.

And in general unless you want to be a pioneer with arrows in your back (and are capable of debugging the resulting messes yourself) it’s just better to stick with what is tried and tested and debugged because everyone else has been using the same versions for years already.