Closed cr8601 closed 3 years ago
It's glibc compatibility check, the simplest solution is rebuild toolchain on CentOS or RedHat6/7...
You don't need admin access to build a toolchain. Only if you want to install it in a restricted dir. So instead of using --prefix=/opt/riscv put it somewhere that you do have write access to.
Ok, from both comments I see that the recommendation is to compile on the system where the compiler will be used...
That's not what I wanted to read, but I already started.;)
The --prefix option is known to me, but what I meant with no admin rights and no internet access is that I will not be able to install or download any dependencies in a simple way and that's what I am currently stucked at:
error: Cannot download gmp-6.1.0.tar.bz2 from http://gcc.gnu.org/pub/gcc/infrastructure/
make: *** [stamps/build-gcc-newlib-stage1] Error 1
The toplevel Makefile runs riscv-gcc/contrib/download_prerequisites which tries to use wget and then curl. Apparently one of those failed. Why did it fail? Maybe you have a firewall in the way? Or maybe both tools are missing? You could try downloading those files manually with ftp or a browser and put them in the riscv-gcc source dir.
But yes, if other stuff is missing you could run into build problems. I'm used to machines that already have all of the build tools installed, and keep forgetting not everyone installs them.
SiFive has toolchain binaries available for download on our web site. They aren't exactly the same as riscv-gnu-toolchain as they have some patches applied and are configured how we want them to work. But they may work for you. We only support embedded elf cross compilers, not cross linux. See https://www.sifive.com/software and scroll down to the CentOS package.
Ok, I solved the above problem by manually downloading the packages. Now I am stuck at the next problem:
make[2]: Entering directory `<ROOT_PATH>/riscv-gnu-toolchain/build-gcc-newlib-stage1/gcc'
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/sh ../.././riscv-gcc/gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="" \
HEADERS="options.h insn-constants.h config/elfos.h config/newlib-stdint.h config/riscv/riscv.h config/riscv/elf.h config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 LIBC_MUSL=4 TARGET_RISCV_ATTRIBUTE=1" \
/bin/sh ../.././riscv-gcc/gcc/mkconfig.sh tm.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/riscv/riscv-protos.h tm-preds.h" DEFINES="" \
/bin/sh ../.././riscv-gcc/gcc/mkconfig.sh tm_p.h
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/sh ../.././riscv-gcc/gcc/mkconfig.sh bconfig.h
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../.././riscv-gcc/gcc -I../.././riscv-gcc/gcc/build -I../.././riscv-gcc/gcc/../include -I../.././riscv-gcc/gcc/../libcpp/include \
-o build/genmodes.o ../.././riscv-gcc/gcc/genmodes.c
<PREFIX_PATH>/riscv32-unknown-elf/bin/as: unrecognized option '-Qy'
make[2]: *** [build/genmodes.o] Error 1
make[2]: Leaving directory `<ROOT_PATH>/riscv-gnu-toolchain/build-gcc-newlib-stage1/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `<ROOT_PATH>/riscv-gnu-toolchain/build-gcc-newlib-stage1'
make: *** [stamps/build-gcc-newlib-stage1] Error 2
First, I'll keep on trying, but if I cannot get it to work, I'll maybe give the sifive toolchain a try... Thanks for that hint
You are accidentally using a RISC-V assembler with an x86_64 compiler. That won't work. It looks like the problem is that you put $PREFIX/riscv-unknown-elf/bin on your PATH which is a bad idea. The binaries in that dir are for gcc to use, since RISC-V gcc will look for "as" and automically find it in that dir. But if you put it on your path then x86_64 gcc will find it too and break. It is OK to put $PREFIX/bin on your path. It is not OK to put $PREFIX/$TARGET/bin on your path except in rare cases.
I checked, an unfortunately $PREFIX/riscv-unknown-elf/bin is not in my PATH variable. I also started with a "fresh" terminal, but no change. after the error, a 'which as' points me to /usr/bin/as which should be correct in my opinion... Any other idea what to check?
I am currently running the line
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../.././riscv-gcc/gcc -I../.././riscv-gcc/gcc/build -I../.././riscv-gcc/gcc/../include -I../.././riscv-gcc/gcc/../libcpp/include \
-o build/genmodes.o ../.././riscv-gcc/gcc/genmodes.c
manually from within <ROOT_PATH>/riscv-gnu-toolchain/build-gcc-newlib-stage1/gcc
. This gives me the same error.
I am currently searching for the reason, why g++ from /usr/bin/g++ can see <PREFIX_PATH>/riscv32-unknown-elf/bin/as
...
Do you have dot "." on your PATH? The risc-v cross compiler creates a link to the risc-v assembler in the gcc build dir, which the just build gcc will need to compile libraries like libgcc before the compiler gets installed. If you have dot early in your path this can break the build as the native x86_64 compiler will then find and use the risc-v cross assembler instead of the one in /usr/bin.
In general, putting dot in your path is a security risk, as an attacker could put malware somewhere you might cd into, with a common utility name like ls, and then you accidentally end up running the malware when you try to run ls. If you do need to put dot on your path, put it at the very end.
Also note that a patch that starts or ends with a colon, or has two colons in a row, is equivalent to having dot on your path.
Adding the gcc -v (for verbose) option will show you what the gcc driver is doing, including which assembler and linker it is using.
Thanks, the "." in my PATH variable was the solution. But I am coming to the next problem:
configure: error: *** A compiler with support for C++11 language features is required.
make[1]: *** [configure-gdbsupport] Error 1
make[1]: Leaving directory `<ROOT_PATH>/riscv-gnu-toolchain/build-gdb-newlib'
make: *** [all] Error 2
Unfortunately our RedHat 6 system only offers:
g++ --version
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
Copyright (C) 2010 Free Software Foundation, Inc.
Our admin already told me there will be no update I'll try to ask google for any alternative. Maybe someone has an idea?
Thanks for your support!
You can get updated compilers from here https://www.softwarecollections.org/en/ and the gcc-8 package is https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/ However, that assumes an admin will install it for you.
You could use the gcc-4 to build gcc-5 etc until you get a recent enough compiler but that would be a lot of work.
In theory it is possible to cross build red hat compiler on ubuntu but it would be a lot of work.
You can download embedded elf cross compilers from the SiFive web site which is the easiest solution. CodeSourcery (Siemens) also has toolchains that can be downloaded.
Hi, currently I go with the SiFive Toolchain unless I have something else.
Probably I'll setup a VM with CentOs and try to create the toolchain there... I think I need to learn a lot on how this SiFive toolchain is built. In the end they are exactly doing what I would like to do: Building an "universal" tarball for RedHat/CentOs that just needs to be unpacked and used...
Thanks a lot for your help! Best regards cr8601
Hi, I can build and use the toolcahin successfully within my Ubuntu machine (Here I have admin rights and internet access).
Now I also want to use it on our RedHat6/7 servers where I do not have any admin rights and internet access. Simply copying the toolchain directory results in
risc32-unknown-elf-gcc: /lib64/libc.so.6: version 'GLIBC_2.14' not found
I am not that familiar with this stuff, but I assume it has to do with the usage of shared libraries!? Is there any option that inlcudes all the required stuff into the make process on Ubuntu that allows me to simply copy it to the RedHat machines?
Or do you have any other suggestion to target my issue?
Thanks and best regards cr8601