Maybe I've got a silly question, but I stuck with that issue. I'm trying to do cross compilation using clang-5.0 of simple test program for target aarch64-cros-linux-gnu:
int main(int argc, const char **argv)
{
return 0x2;
}
So, when I'm running clang with the next command:
/home/alex/Dev/CustomToolchains/Google/clang-5.0/aarch64/usr/bin/clang --sysroot=/home/alex/Dev/CustomToolchains/Google/clang-5.0/aarch64/usr/aarch64-cros-linux-gnu -Qunused-arguments -grecord-gcc-switches -fPIE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -pie -fno-omit-frame-pointer main.cxx -o main3 -B/home/alex/Dev/CustomToolchains/Google/clang-5.0/aarch64/bin -target aarch64-cros-linux-gnu
I'm getting an error:
ld.bfd: no input files
clang: error: linker command failed with exit code 1 (use -v to see invocation)
But when I'm removing --sysroot and -target parameters everything is ok. I have checked --sysroot path and it's exists but I'm not sure if it correct. clang docs says that this folder must contain bin, lib, include directories, but in the sysroot directory there are only next folders:
lib lib64 NOTICE-eglibc NOTICE-gdb sbin sys-include usr var
So, how I can specify correct toolchain path to the clang for my target triple aarch64-cros-linux-gnu? or where I can get that toolchain?
Big thanks for answers.
PS. I'm a newbie with all linux/clang/cros compilation -related staff, so I'm sorry for mistakes in my question.
Related
I am trying to compile for a gd32v chip using gcc(the riscv version on the arch community repo).
Compiling seems to work fine, however when trying to link the objects into an elf file, I get the error:
Linking ELF target: main.elf
riscv64-linux-gnu-g++ #_linker_flags -o main.elf ../../bmptk-RISC-V/targets/risc_v/gd32v/gd32vf103xb_boot.o hwlib.o main.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Source/gd32vf103_rcu.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Source/gd32vf103_gpio.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/system_gd32vf103.o bmptk_heap_none.o bmptk_fixed_size_stack.o -Os -Tmain.ld
/usr/lib/gcc/riscv64-linux-gnu/10.2.0/../../../../riscv64-linux-gnu/bin/ld: /usr/lib/gcc/riscv64-linux-gnu/10.2.0/../../../../riscv64-linux-gnu/lib/libstdc++.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make: *** [../../bmptk-RISC-V/Makefile.inc:1498: main.elf] Error 1
In this make rule, I am using a file '_linker_flags' for my linker flags, to keep the terminal clean during compilation. The contents of this file are as follows:
-march=rv32imac -mabi=ilp32 -Os -fdata-sections -ffunction-sections -I../../bmptk-RISC-V/targets/risc_v/ -I../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral -I../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Include -I../../bmptk-RISC-V/targets/risc_v/RISCV/drivers -I../../bmptk-RISC-V/targets/risc_v -I/usr/include -I/usr/include -I../../hwlib-RISC-V/library -I../../Catch2/single_include -I../../Catch2/single_include/catch2 -I../../boost_1_69_0 -I../../bmptk-RISC-V -I../../bmptk-RISC-V/targets -I../../bmptk-RISC-V/targets/risc_v -I../../bmptk-RISC-V/targets/risc_v/RISCV -I../../bmptk-RISC-V/targets/risc_v/RISCV/drivers -DHWCPP_FAKE_OSTREAM -DBMPTK_TARGET=gd32vf103v -DBMPTK_TARGET_gd32vf103v -DHWLIB_TARGET_gd32vf103v -DHWCPP_TARGET_gd32vf103v -DGF_TARGET_gd32vf103v -DBMPTK_CHIP=gd32vf103v -DBMPTK_CHIP_gd32vf103v -DBMPTK_XTAL= -DBMPTK_BAUDRATE=38400 -DHWLIB_BAUDRATE=38400 -DGODAFOSS_BAUDRATE=38400 -DGF_BAUDRATE=38400 -DBMPTK_VERSION=V04_00_work_in_progress_2020_05_23 -DBMPTK_EMBEDDED -lgcc -Wl,-Map,main.map -Wl,--gc-sections -Wl,-fatal-warnings
I'm not familiar with this error, does anyone know what I would have to look into to fix this?
EDIT:
I asked a teacher at school and they told me that the problem most likely arised from using a mismatching linker and compiler, or that some object files weren't cleaned when calling make. I made sure all objects were deleted before compiling and made sure the compiler and linker were the same.
They should be the same. I am running riscv64-linux-gnu-ld version 2.35 and riscv64-linux-gnu-g++ version 10.2.0. Both are from the arch community repository.
To see exactly the mapping/switches of the libraries supported by your compiler you can use : riscv64-linux-gnu-g++ -print-multi-lib. If you compiler was compiled with multilib enabled you can choose an rv32 libs without hard float otherwise it will not link also since you are compiler for rv32imac.
If your compiler was build without the multlib option you have two option:
Compile with -nostdlib and provide the needed file to the linker crt, libc libgcc ... or you can get a compiler which was build with multilib enabled.
I have been using gtests for unit testing a personal project. Last week I upgraded to the LTS version of Linux Mint. Unfortunately, after that event, I haven't been able to compile my project due to gtests linking problems.
The following error is being issued:
/usr/bin/x86_64-linux-gnu-ld: build/tests/policies/roundrobin_tests.o: undefined reference to symbol '_ZN7testing4TestC2Ev'
/home/myuser/Documents/googletest-release-1.8.0/googletest/libgtest.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I have generated both libgtest.so and libgtest_main.so through CMake 3.10.2. The gtest version is the release-1.8.0, the same I used to have before.
Those libraries are located in /usr/lib and the corresponding include folder has also been copied to /usr/include. I made sure that this location is in my ld path and that is not the problem.
My compiler is g++ v7.3.0 and the command Im using to compile the testes is:
g++ -std=c++14 -Wall -O3 -Iinclude build/tests/policies/roundrobin_tests.o -lgtest_main -pthread -o bin/policies/roundrobin_tests
I have tried altering the order of the elements in the command, explicitly adding -L/usr/lib and -I/usr/include without luck. A funny fact is that if I take off the -pthread flag, the error is still the same.
The same command was used before and the only difference is the compiler version I am using now as I used g++ 5.4.0 before. Any insights on how to solve this?
edit: Just tested the same process with g++ 5.4.0 and CMake 3.5 and the same problems ocurred.
I am trying to compile a minimal C++ code
#include <iostream>
#include <mkl.h>
#include <omp.h>
int main(int argc, char *argv[])
{
omp_set_num_threads(4);
return 0;
}
using the MKL library (icc version 17.0.4) in a MacOSX Sierra 10.12.5, using the command
icc main.cpp -o main.o -DMKL_ILP64 -I/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/include \
-L/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/lib -Wl,-rpath,/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/lib -lmkl_intel_ilp64 \
-lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl
However I receive the following error when I run the program
dyld: Library not loaded: #rpath/libiomp5.dylib
Referenced from: /Users/user/C++/MKL1/./main.o
Reason: image not found
/bin/sh: line 1: 8898 Abort trap: 6 ./main.o
make: *** [run] Error 134
How to set up properly the openmpi with the MKL library? I tried to follow the instruction in https://software.intel.com/en-us/articles/dyld-library-not-loadedlibiomp5dylib?page=1#comment-1905809
by adding
source /opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/bin/mklvars.sh intel64
However I still get the same error during runtime.
I have tried a few ways to solve this issue. It literally took an entire day. But here are the results,
Project Files
I created a very simple Project with just one file, named,
test.c
1. The Easiest Solution
Fixing this can be as simple as,
icc -qopenmp -qopenmp-link=static test.c
This method just tells the compiler to link to static OpenMP run-time libraries.
Interestingly, the docs at Intel C++ Compiler Docs v.15 say that this is deprecated while Intel C++ Compiler Docs v.17 do not even mention about this argument, BUT it works. Probably they forgot to take it out.
2. Another method (which I do not recommend, nor do folks at Intel)
To compile the file you can use the normal "-qopenmp" flag
icc -qopenmp test.c
This creates the "a.out" file.
This method of fixing the error makes use of command-line utility called,
install_name_tool
Using this method we can change the path of #rpath/libiomp5.dylib
install_name_tool -change #rpath/libiomp5.dylib /opt/intel/compilers_and_libraries_2018.1.126/mac/compiler/lib/libiomp5.dylib a.out
Note: In place of compilers_and_libraries_2018.1.126 it should be your version of the compiler.
3. One of the BEST (correct) ways
You can just add
export DYLD_LIBRARY_PATH="/opt/intel/compilers_and_libraries_2018.1.126/mac/compiler/lib"
To your ~/.bash_profile
And then use the normal way of compiling,
icc -qopenmp test.c
Everything works perfectly.
Quick tip: You can use the otool command line utility to check the libraries your file links to.
otool -L a.out
I found the answer on https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/645194
Basically one has to add
-Wl,-rpath,/opt/intel/compilers_and_libraries_2017.4.181/mac/compiler/lib
during compilation. Now openmp with icc works perfectly
I am trying to compile as this :
-bash-4.1$ g++ -static -m32 Hello.cpp
and getting errors like this:
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: skipping incompatible /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/libstdc++.a when searching for -lstdc++
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
I have tried this as well but still get the exact same error above:
g++ -static -m32 -L/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32 Hello.cpp
I have tried in both orders - nothing helps.
Why is it still looking at the wrong directory?
Is using -m32 option override -L option?
I could not find much documentation on -m32 option.
Please help.
Thanks!
Why is it still looking at the wrong directory?
Compiler always looking in predefined directories first. -L options adds your path to these list of directories, so because of it compiler is stil looking at the wrong directory. For more detailed output try to compiler your program with detailed output -### or -v options.
Is using -m32 option override -L option?
The answer is no - -m32 options is option to generate 32bit code, for example:
You may generate 32bit code that will work on 32bit machine, on your 64bit machine. Also you may run this code on your 64bit machine - it will work well.
I could not find much documentation on -m32 option.
Here is the link to the GCC docs
And here is doc about directory searching options
Also to say to compiler where to find libraries, you may set
LD_LIBRARY_PATH in your env
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$FULL_PATH_TO_YOUR_LIB
Do not override env vars - cause it may cause more problems if you are not absolutely sure in what you are doing.
I am doing tests for my code with GoogleTest (1.7.0). I must have the tests compiling in both NetBeans (8.0.2) and straight from command line.
NetBeans has GoogleTest integrated as suggested here: https://youtu.be/TS2CTf11k1U.
I have also build GoogleTest from the command line (in different place) with the instructions provided with the package.
The problematic line of code is (a and b are doubles):
std::string input = std::to_string(a) + " " + std::to_string(b);
which gives error: ‘to_string’ is not a member of ‘std’, when compiling with
g++ -isystem -std=c++0x ~/gtest-1.7.0/include -pthread ~/Task1/test_source.cpp libgtest.a -o test_module1_1
as instructed in GoogleTest documentation.
The strange thing here is that when using the "Test" from NetBeans (as seen on video), the tests compile and run correctly.
I am using Ubuntu 14.04 and I have already tried to update g++ (not to a higher version though), and I have also tried specifying the version with -std=c++11 instead of -std=c++0x.
In NetBeans there is this warning visible:
Library File /usr/include/c++/4.8/string
but there is an unresolved #include <stddef.h>
in included /usr/include/_G_config.h
I found out that this might be because multilib and I have also tried to fix that by checking that it is installed. And this doesn't really cause any warnings during compile so it might be just that the IDE is confused.
But conserning the real problem about compile errors:
Is there something wrong with the GoogleTest framework, the compiler or my code?
PS. Preferably don't suggest that I just don't use to_string as this system must be usable by students studying C++11 and really it shouldn't be that they can't use all the functionality that should be supported.
I think your problem is the order in which you're passing command line arguments to gcc
g++ -isystem -std=c++0x ~/gtest-1.7.0/include ...
^^^^^^^^^^^^^^^^^^^
The -isystem flag should be followed by a path that contains headers which you want gcc to treat as system headers. So the -std=c++0x flag is being incorrectly consumed by the -isystem flag. You probably want the command line to be
g++ -std=c++0x -isystem ~/gtest-1.7.0/include ...