Cannot find -lstdc++

[minhoha]

I build LLVM & Clang and it works well with simple vector addition C code.

clang --target=riscv64-unknown-elf -march=rv64gcv1p0 -menable-experimental-extensions -O2 -c -o riscv_aligned.o riscv_aligned.cpp

works well. However,

riscv64-unknown-elf-g++ riscv_aligned.o -o riscv_aligned_20210408 -march=rv64gcv1p0 -mabi=lp64d

command doesn't work. The following error occurs.

/home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status

Has anyone solved a problem like this? Does anyone know how to solve it?

[zakk0610]

use clang++?

[minhoha]

use clang++?

@zakk0610
Yes, I've tried "clang++" too

[zakk0610]

You can use g++ to compile a C++ source code with -v to see -L path and find out where is your libstdc++.a

[minhoha]

@zakk0610

Here is the result, which compile with -v,

root@rpm-System-Product-Name:~/sls# riscv64-unknown-elf-g++ -v riscv_aligned.o -o riscv_aligned_20210408 -march=rv64gcv1p0 -mabi=lp64d
Using built-in specs.
COLLECT_GCC=riscv64-unknown-elf-g++
COLLECT_LTO_WRAPPER=/home/mhha/_install/bin/../libexec/gcc/riscv64-unknown-elf/10.1.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: /home/mhha/riscv-gnu-toolchain/riscv-gcc/configure --target=riscv64-unknown-elf --prefix=/home/mhha/riscv-gnu-toolchain/../_install --disable-shared --disable-threads --enable-languages=c,c++ --with-system-zlib --enable-tls --with-newlib --with-sysroot=/home/mhha/riscv-gnu-toolchain/../_install/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
gcc version 10.1.0 (GCC)
COMPILER_PATH=/home/mhha/_install/bin/../libexec/gcc/riscv64-unknown-elf/10.1.0/:/home/mhha/_install/bin/../libexec/gcc/:/home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/bin/
LIBRARY_PATH=/home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/:/home/mhha/_install/bin/../lib/gcc/:/home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/:/home/mhha/_install/bin/../riscv64-unknown-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'riscv_aligned_20210408' '-march=rv64gcv1p0' '-mabi=lp64d' '-mtune=rocket' '-march=rv64imafdc_v1p0_zvamo_zvlsseg'
/home/mhha/_install/bin/../libexec/gcc/riscv64-unknown-elf/10.1.0/collect2 -plugin /home/mhha/_install/bin/../libexec/gcc/riscv64-unknown-elf/10.1.0/liblto_plugin.so -plugin-opt=/home/mhha/_install/bin/../libexec/gcc/riscv64-unknown-elf/10.1.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccsS4Tn7.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgloss -plugin-opt=-pass-through=-lgcc --sysroot=/home/mhha/_install/bin/../riscv64-unknown-elf -melf64lriscv -o riscv_aligned_20210408 /home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/crt0.o /home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/crtbegin.o -L/home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0 -L/home/mhha/_install/bin/../lib/gcc -L/home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib -L/home/mhha/_install/bin/../riscv64-unknown-elf/lib riscv_aligned.o -lstdc++ -lm -lgcc --start-group -lc -lgloss --end-group -lgcc /home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/crtend.o
/home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status

[jim-wilson]

This could be a build problem. Maybe you don't have a libstdc++. This could be a multilib problem. Maybe you do have a libstdc++, but you don't have a V libstdc++. I would suggest trying the commands
riscv64-unknown-elf-gcc --print-file-name=libstdc++.a
riscv64-unknown-elf-gcc --print-file-name=libstdc++.a -march=rv64gcv
Both should print full path names to the libstdc++.a file. If neither does, then you have no libstdc++ file. If the first one does and the second one does not, then you have a libstdc++ file but not a V one.

If you aren't calling any library functions with vector arguments, you may not need the V in -march option when linking. You could try linking without the V march and see if that works.

[minhoha]

@jim-wilson

Thank you for your answer.

Here are the results what you suggest,

root@rpm-System-Product-Name:~/sls# riscv64-unknown-elf-gcc --print-file-name=libstdc++.a
/home/mhha/_install/bin/../lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/rv64imafdc/lp64d/libstdc++.a

and

root@rpm-System-Product-Name:~/sls# riscv64-unknown-elf-gcc --print-file-name=libstdc++.a -march=rv64gcv
libstdc++.a

"riscv_aligned.cpp" file need RISC-V vector extension.
What can I do in this case?

[jim-wilson]

You can use --with-arch=rv64gcv when configuring the toolchain, which will build libraries like libstdc++ with rv64gcv. If you don't specify --with-arch when configuring, then the default is rv64gc and libstdc++ will be built with that. Though it isn't clear to me why you need a vector libstdc++. Just because your program is compiled with vector support doesn't mean that you need a libstdc++ compiled with vector support. The ABI for non-vector code doesn't change when compiled with vector instructions. So you should be able to link your vector code with a non-vector libstdc++. Just drop the -march option when linking.

[minhoha]

@jim-wilson

Thanks a lot!! It works!!

[minhoha]

@jim-wilson

In our cpp file, we are using the "aligned_alloc" function.
After we command,

riscv64-unknown-elf-g++ riscv_aligned.o -o riscv_aligned_20210409 -march=rv64gcv1p0 -mabi=lp64d

the results are

/home/mhha/_install2/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/bin/ld: riscv_aligned.o: in function .LBB9_6': riscv_aligned.cpp:(.text+0xb42): undefined reference to sleep'
/home/mhha/_install2/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/bin/ld: /home/mhha/_install2/lib/gcc/riscv64-unknown-elf/10.1.0/../../../../riscv64-unknown-elf/lib/libc.a(lib_a-aligned_alloc.o): in function aligned_alloc': aligned_alloc.c:(.text+0xa): undefined reference to posix_memalign'
collect2: error: ld returned 1 exit status

Can we use 'sleep' and 'aligned_alloc' ??

[jim-wilson]

An embedded elf toolchain provides a limited set of library functions. It is hard to support sleep when you don't have an OS. There is no one tracking all standards to ensure all possible library functions are added. An embedded elf C library just supports the most common functions. It looks like aligned_alloc is supported but posix_memalign isn't.

If you want a full featured C library, you should use a linux toolchain instead of an embedded elf toolchain. But if you do use a linux toolchain, and a lot of C libary features, then the code will probably only run on qemu. spike+pk only supports a limited number of system calls.

[minhoha]

@jim-wilson

Thanks for your adivce.

riscv64-unknow-liinux-gnu-g++ works, however, there exists linker problem.
When I run QEMU, I got linker error like this,

/lib/ld-linux-riscv64-lp64d.so.1: No such file or directory

I'm going to address the current problem by commenting out sleep first and replacing aligned_alloc with malloc.
Could you please give me some advice on linker issues?

[jim-wilson]

You probably need to pass an option to qemu to tell it where your sysroot is. qemu will then find ld.so and other shared libraries inside the sysroot. Checking riscv-gnu-toolchain, we pass a -L $RISC_V_SYSROOT option to qemu, where RISC_V_SYSROOT is an environment variable set by the Makefile to point at $prefix/sysroot. You also need to make sure that you do have the file inside your sysroot. Try using ls to make sure the file is there. If not, then there is something wrong with your compiler and/or C library. You can always try linking statically if you can't figure out how to make shared libraries work.