build error

[dragonware-com]

So I built the riscv-gnu-toolchain without any problem (https://github.com/pulp-platform/pulp-riscv-gnu-toolchain), however, cmake_configure.zeroriscy.gcc.sh execution has some problems:

1. it says -m32 is not supported. So I removed the -m32 in cmake_configure.zeroriscy.gcc.sh. Then it has the second problem:

2. riscv32-unknown-elf/bin/ld: cannot open linker script file riscv.ld: No such file or directory

[dragonware-com]

The the fundamental problem I figured out is related to cmake.
When cmake is probing the compiler, it tries to compile a very simple code. However, for some reason, cmake is not using CMAKE_EXE_LINKER_FLAGS specified in the CMakeLists.txt. Maybe it is caused by the way the script is calling cmake: the script used -DCMAKE_C_FLAGS on the command line, which makes cmake not using CMAKE_EXE_LINKER_FLAGS for linking? But then, the cmake compiler probing is a single "gcc" call, instead of a "gcc -c" followed by "ld".

One workaround is to modify the cmake_configure.zeroriscy.gcc.sh script to add the linker flags to the C_FLGAS in the script, but this is more like a hack.

Another idea is to somehow make the riscv gcc use a default linker script so that it passes compiler probing, but use user-specified flags during real compilation. However, the riscv-gcc toolchain I compiled from the pulp doesn't seem to have a default linker script thus failing the compiler probe.

Any ideas/comments?

[dragonware-com]

After working around the -m32 and compiler probing problem, now there is another problem "make helloworld":

riscv32-unknown-elf/bin/ld: unrecognised emulation mode: elflriscv
Supported emulations: elf32lriscv elf64lriscv

[haugoug]

pulp-riscv-gnu-toolchain cannot be used with the current pulpino cmake flow you have to use this compiler instead: https://github.com/pulp-platform/ri5cy_gnu_toolchain

[FrancescoConti]

I believe the correct toolchain for PULPino is this one: https://github.com/pulp-platform/ri5cy_gnu_toolchain (the one you are using is more up to date and we use it for PULP / PULPissimo, and it is used by derivatives e.g. https://github.com/GreenWaves-Technologies/gap_sdk). However, I am assigning the issue to @haugoug who might know better.

[FrancescoConti]

Whoops, @haugoug was too fast for me :)

[dragonware-com]

That's good to know. Thanks for the replies!

[dragonware-com]

Well, the problem with https://github.com/pulp-platform/ri5cy_gnu_toolchain is that it failed to build:

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/home/wsun/ri5cy_gnu_toolchain/build/src/binutils/bfd -I. -I/home/wsun/ri5cy_gnu_toolchain/build/src/binutils/bfd -I/home/wsun/ri5cy_gnu_toolchain/build/src/binutils/bfd/../include -DHAVE_riscv_elf32_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -DHAVE_plugin_vec -DBINDIR="/home/wsun/ri5cy_gnu_toolchain/install/bin" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -MT elf32-riscv.lo -MD -MP -MF .deps/elf32-riscv.Tpo -c elf32-riscv.c -o elf32-riscv.o
/home/wsun/ri5cy_gnu_toolchain/build/src/binutils/bfd/elfxx-riscv.c:26:17: fatal error: bfd.h: No such file or directory
compilation terminated.
Makefile:1607: recipe for target 'elfxx-riscv.lo' failed
make[5]: *** [elfxx-riscv.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
/home/wsun/ri5cy_gnu_toolchain/build/src/binutils/bfd/elfnn-riscv.c:28:17: fatal error: bfd.h: No such file or directory
compilation terminated.

[mbolivar]

riscv32-unknown-elf/bin/ld: cannot open linker script file riscv.ld: No such file or directory

I'm running into the same problem trying to use this toolchain with CMake.

In particular, the project I'm working on uses a line like check_c_compiler_flag("" toolchain_is_ok) in CMake to test that the C compiler can build and link a basic file (src.c below, which just contains int main(void) { return 0; }). The result is the above error, as check_c_compiler_flag() does a "compiler probe" probably very similar to what was originally reported:

/home/mbolivar/bin/pulp-toolchain/bin/riscv32-unknown-elf-gcc   -Dtoolchain_is_ok -nostartfiles -nostdlib -isystem "/home/mbolivar/bin/pulp-toolchain/bin/../lib/gcc/riscv32-unknown-elf/7.1.1/include" -isystem "/home/mbolivar/bin/pulp-toolchain/bin/../lib/gcc/riscv32-unknown-elf/7.1.1/include-fixed" -Wl,--unresolved-symbols=ignore-in-object-files -o CMakeFiles/cmTC_68b99.dir/src.c.obj   -c src.c

/home/mbolivar/bin/pulp-toolchain/bin/riscv32-unknown-elf-gcc -Dtoolchain_is_ok -nostartfiles -nostdlib -isystem "/home/mbolivar/bin/pulp-toolchain/bin/../lib/gcc/riscv32-unknown-elf/7.1.1/include" -isystem "/home/mbolivar/bin/pulp-toolchain/bin/../lib/gcc/riscv32-unknown-elf/7.1.1/include-fixed" -Wl,--unresolved-symbols=ignore-in-object-files   CMakeFiles/cmTC_68b99.dir/src.c.obj  -o cmTC_68b99

Another idea is to somehow make the riscv gcc use a default linker script so that it passes compiler probing, but use user-specified flags during real compilation. However, the riscv-gcc toolchain I compiled from the pulp doesn't seem to have a default linker script thus failing the compiler probe.

@dragonware-com you wouldn't happen to have any patches doing this floating around, would you?

I tried just creating an empty riscv.ld in the temporary CMake build directory which is being used by check_c_compiler_flag and the build system was able to generate an executable, so I'm wondering if that's enough.

Well, the problem with https://github.com/pulp-platform/ri5cy_gnu_toolchain is that it failed to build:

I'm stuck on the same at this point. @FrancescoConti, @haugoug, any advice appreciated.

[zejiang0jason]

pulp-riscv-gnu-toolchain cannot be used with the current pulpino cmake flow you have to use this compiler instead: https://github.com/pulp-platform/ri5cy_gnu_toolchain

Hi @haugoug , as you said, pulp-riscv-gnu-toolchain cannot be used with the pulpino cmake flow. But the pulp-riscv-gnu-toolchain readme.md told that

This will use the multilib support to build the libraries for the various cores (riscy, zeroriscy and so on). The right libraries will be selected depending on which compiler options you use.

Does it mean that the pulp-riscv-gnu-toolchain supports pulpino cores with some cmake modification? Thank you very much.

[haugoug]

Indeed pulp-riscv-gnu-toolchain should supports pulpino, this just requires a few modifications in the pulpino cmake flow.
It is probably better to make these modifications and use pulp-riscv-gnu-toolchain as ri5cy_gnu_toolchain is quite old.

[zejiang0jason]

Indeed pulp-riscv-gnu-toolchain should supports pulpino, this just requires a few modifications in the pulpino cmake flow.
It is probably better to make these modifications and use pulp-riscv-gnu-toolchain as ri5cy_gnu_toolchain is quite old.

Thank you very much, haugoug

[jasonchu024]

So I just come across exactly the same problem, ri5cy_gnu_toolchain is failed to build, pulp-riscv-gnu-toolchain can be built but it doesn't support pulpino. Could @haugoug suggest a fix to the cmake flow?

[mbolivar]

The the fundamental problem I figured out is related to cmake.
When cmake is probing the compiler, it tries to compile a very simple code. However, for some reason, cmake is not using CMAKE_EXE_LINKER_FLAGS specified in the CMakeLists.txt. Maybe it is caused by the way the script is calling cmake: the script used -DCMAKE_C_FLAGS on the command line, which makes cmake not using CMAKE_EXE_LINKER_FLAGS for linking? But then, the cmake compiler probing is a single "gcc" call, instead of a "gcc -c" followed by "ld".

One workaround is to modify the cmake_configure.zeroriscy.gcc.sh script to add the linker flags to the C_FLGAS in the script, but this is more like a hack.

Another idea is to somehow make the riscv gcc use a default linker script so that it passes compiler probing, but use user-specified flags during real compilation. However, the riscv-gcc toolchain I compiled from the pulp doesn't seem to have a default linker script thus failing the compiler probe.

Any ideas/comments?

@dragonware-com I found a solution, by adding the following to my CMake files before doing the compiler probing:

set(CMAKE_REQUIRED_FLAGS -Wl,-dT=${CMAKE_CURRENT_LIST_DIR}/empty-file.ld)

The CMAKE_REQUIRED_FLAGS variable is exactly what you write about: it allows setting options for compiler probing only. It is not used during real compilation.

[mbolivar]

(Note that you need to make an empty file named "empty-file.ld" in the directory containing your CMakeLists.txt for the above to work)

[dragonware-com]

@haugoug Great! Thanks for the effort!

[mbolivar]

@haugoug Great! Thanks for the effort!

I am not hagoug but you are welcome!

[dragonware-com]

@mbolivar Sorry, thank you for the effort!

[jasonchu024]

set(CMAKE_REQUIRED_FLAGS -Wl,-dT=${CMAKE_CURRENT_LIST_DIR}/empty-file.ld)

@mbolivar, the issue remains on me, should I add this to the CMakeList.txt file before cmake version probing? Thanks.

[mbolivar]

set(CMAKE_REQUIRED_FLAGS -Wl,-dT=${CMAKE_CURRENT_LIST_DIR}/empty-file.ld)

@mbolivar, the issue remains on me, should I add this to the CMakeList.txt file before cmake version probing? Thanks.

Hi @jasonchu024, I assume you are using a CMake function like check_c_compiler_flag() or some other function that calls check_c_source_compiles() as the "compiler probe" discussed in previous comments. In that case, yup, you will need to set this variable first. See https://cmake.org/cmake/help/latest/module/CheckCSourceCompiles.html#module:CheckCSourceCompiles for details.

[sofchet]

@mbolivar or @dragonware-com can you please specify where set(CMAKE_REQUIRED_FLAGS -Wl,-dT=${CMAKE_CURRENT_LIST_DIR}/empty-file.ld) shoud be added ?
I mean which cmake files are talking about ? I am a bit confused, like where these files ( or is it only one file ) is supposed to be located at ? the same thing for the CMakelist.txt, where is it located ?

Thanks

[mbolivar]

@sofchet I'm not sure how to answer your question unfortunately.

People's individual CMake projects are going to vary a lot. They may contain one or more CMakeLists.txt files to control the project build. There may be multiple projects being integrated into a parent build system in this way.

I've tried to clarify that if toolchain checks in functions like check_c_compiler_flag are the problem, they can be worked around as described above by using a dummy linker script. (If you already have a real linker script to use at this point in the build, so much the better, but the environment I'm working on can't figure out the real linker script until later in the build so I have to provide a dummy via -dT at this stage.)

See for example https://sourceware.org/binutils/docs/ld/Scripts.html for more information on linker scripts.

See the gcc manpage for details on -Wl and the ld manpage for details on -dT.

Good luck!

[mbolivar]

Hi --- I just thought I'd ping this issue again.

In my opinion, something is misconfigured with this ld. You can run riscv32-unknown-elf-ld --verbose and get a full linker script, so the tool knows what to do by default.

Forcing the user to create a riscv.ld seems like a bug then: all the information to do a default link is already available to the linker. If that file is missing, there should be no error.

[stefanct]

Hi,
thanks for some very useful hints in this report. Unfortunately, I am not able to get it working with current master (aka Pulpino_v2.1-367-g0cdfddd) though. My goal for now is to simply get sw/cmake_configure.riscv.gcc.sh working with pulp-platform/pulp-riscv-gnu-toolchain. I can confirm that riscv32-unknown-elf-ld --verbose outputs something that looks like a valid linker script. I have tried to modify the cmake call in the shell script to use a given linker script by setting -DCMAKE_C_FLAGS="-Wl,-dT=$(realpath ../empty-file.ld)".

With an empty linker script I get this as first error (when linking):

In function `_start':
(.text+0x8): undefined reference to `__global_pointer$'

(followed by _fbss and _end).

When I change the linker script to the output of riscv32-unknown-elf-ld --verbose I get

In function `.L0 ':
(.text+0x10): undefined reference to `_fbss'

(that is indeed not mentioned in the linker script). FWIW, I was creating the toolchain using --with-arch=rv32imc --with-cmodel=medlow --enable-multilib. No idea why this is different to the results of @mbolivar. :/

[zejiang0jason]

Hi @stefanct ,

About the error:

In function `.L0 ':
(.text+0x10): undefined reference to `_fbss'

The symbol _fbss required by crt0.o is not defined in the *.ld file. After checking the newlib code,
https://github.com/pulp-platform/pulp-riscv-newlib/blob/1e52935101d096bb2e9381c7b131d6b976f0acd9/libgloss/riscv/crt0.S,
the _fbss is previously named _edata. I modified _fbss back to _edata, and rebuild the toolchain, the error disappears.

Another solution I think is, don't use the crt0.o, by adding build parameter -nostartfiles and using your own startup code.

[zejiang0jason]

Hi,

I found the issue about missing riscv.ld is because of the LINK_SPEC defined in https://github.com/pulp-platform/pulp-riscv-gcc/blob/daa865ea46d212dee71872cabd390f700ac2f0c4/gcc/config/riscv/elf.h

The flag %{!T:-dT riscv.ld} means if the T is not defined in link command, then use -dT riscv.ld. The detailed explanation could be found here. I removed this line and rebuild the toolchain, the issue disappears.

[sunil3690]

How to generate bitstream on pulpino using fpga zedboard or zybo. set the environment variable BOARD. In the tcsh script file as steven BOARD "Zybo" also i did not specify the BOAD PART and BOARD NUMBER it will take default XILINX_PART "xc7z020clg484-1" XILINX_BOARD "em.avnet.com:zynq:zed:c" inside the environment variable set "RISCY_RV32F" and set the vivado toolchain PATH and Xilinx SDK PATH as export PATH=/root/pulpino/ri5cy_gnu_toolchain/install/bin:$PATH export LD_LIBRARY_PATH=/root/pulpino/Xilinx/Vivado/2019.1/lib/lnx64.o export PATH=/root/pulpino/Xilinx/Vivado/2019.1/bin:$PATH export PATH=/root/pulpino/Xilinx/SDK/2019.1/bin:$PATH export PATH=/root/pulpino/Xilinx/SDK/2019.1/gnu/microblaze/lin/bin:$PATH export PATH=/root/pulpino/Xilinx/SDK/2019.1/gnu/armr5/lin/gcc-arm-none-eabi/bin:$PATH export PATH=/root/pulpino/Xilinx/SDK/2019.1/gnu/microblaze/linux_toolchain/lin64_le/bin:$PATH export PATH=/root/pulpino/Xilinx/DocNav:$PATH After this i type "make all" targated to *"cmake_configure.riscvfloat.gcc.sh <http://cmake_configure.riscvfloat.gcc.sh/>"* in the fpga directory i am getting an error as root@sunil-Inspiron-3542:~/pulpino/fpga# make all make -C ips/xilinx_fp_fma/ clean all make[1]: Entering directory '/root/pulpino/fpga/ips/xilinx_fp_fma' rm -rf ip/* mkdir -p ip rm -rf xilinx_fp_fma.xpr rm -rf xilinx_fp_fma.hw rm -rf xilinx_fp_fma.data rm -rf xilinx_fp_fma.runs rm -rf xilinx_fp_fma.srcs rm -rf xilinx_fp_fma.cache rm -rf component.xml rm -rf vivado*.jou rm -rf vivado*.log rm -rf vivado*.str rm -rf xgui vivado -mode batch -source tcl/run.tcl ****** Vivado v2019.1 (64-bit) **** SW Build 2552052 on Fri May 24 14:47:09 MDT 2019 **** IP Build 2548770 on Fri May 24 18:01:18 MDT 2019 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved. source tcl/run.tcl # if { ![info exists ::env(XILINX_PART)] } { # set ::env(XILINX_PART) "xc7z020clg484-1" # } # if { ![info exists ::env(XILINX_BOARD)] } { # set ::env(XILINX_BOARD) "em.avnet.com:zynq:zed:c" # } # set partNumber $::env(XILINX_PART) # set boardName $::env(XILINX_BOARD) # create_project xilinx_fp_fma . -part $partNumber ERROR: [Common 17-53] User Exception: Project already exists on disk, please use '-force' option to overwrite: /root/pulpino/fpga/ips/xilinx_fp_fma/xilinx_fp_fma.ip_user_files INFO: [Common 17-206] Exiting Vivado at Mon Oct 21 16:41:39 2019... Makefile:4: recipe for target 'all' failed make[1]: *** [all] Error 1 make[1]: Leaving directory '/root/pulpino/fpga/ips/xilinx_fp_fma' Makefile:33: recipe for target 'ips/xilinx_fp_fma/ip/xilinx_fp_fma.dcp' failed make: *** [ips/xilinx_fp_fma/ip/xilinx_fp_fma.dcp] Error 2 please let me know the issue. Thank you also please let know how to Prepare the SD card and the ZedBoard for booting via SD card and Extract the content of the rootfs.tar archive and put it on the second partition of the SD card OR it will enough to direct run the "Running applications on PULPino" please can help the issues Thank you

…

On Wed, Oct 23, 2019, 12:25 PM zejiangfish ***@***.***> wrote: Hi, I found the issue about missing riscv.ld is because of the LINK_SPEC defined in https://github.com/pulp-platform/pulp-riscv-gcc/blob/daa865ea46d212dee71872cabd390f700ac2f0c4/gcc/config/riscv/elf.h The flag %{!T:-dT riscv.ld} means if the T is not defined in link command, then use -dT riscv.ld. The detailed explanation could be found here <https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html>. I removed this line and rebuild the toolchain, the issue disappears. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#240?email_source=notifications&email_token=ANAORJNW5LCGZFHLGFH2BYLQP7YO7A5CNFSM4FSZRF4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECAJMJA#issuecomment-545297956>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANAORJJD5QQZ3K37GMK24HLQP7YO7ANCNFSM4FSZRF4A> .

[mbolivar]

The flag %{!T:-dT riscv.ld} means if the T is not defined in link command, then use -dT riscv.ld. The detailed explanation could be found here. I removed this line and rebuild the toolchain, the issue disappears.

Note that doing this would break the build for any users that rely on this file implicitly being used as the linker script. They would all have to update their build systems to use -T riscv.ld manually.