I am new to riscv GNU toolchain. When compiling a program, some errors occured.
A hidden symbol named **'__gtdf2'** in /XXX/bin/../lib/gcc/riscv64-unknown-elf/10.2.0/rv64imac/lp64/libgcc.a(gedf2.o) is referenced by DSO.
This is my compile command:
riscv64-unknown-elf-g++ test.cpp ./libXXX.so -o test.out -I XXX/include/path/ -march=rv64imac -mabi=lp64
I am wondering that my built libgcc.a is uncorrect or some other reasons cause that.
Thanks a lot.
Related
I have some trouble with crosscompiling C++ program which takes advantage of openMP library. I am using Linux Ubuntu 12.04 LTS. I want to obtain executable file runnable on Windows.
I have no problem with compiling my program with OMP with regular g++ command:
g++ a.cpp b.cpp -o OMPres -pg -O3 -I./CBLAS/include -L./ -lcblas
Also when I try crosscompilation without OMP, everything runs perfectly fine:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o res.exe -l gfortran -static
But when I try to crosscompile it with OMP using following command:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I get this error:
a.cpp:41:17: fatal error: omp.h: No such file or directory
compilation terminated.
I found where omp.h file is located on my disk, and added the path to the command. After executing it:
x86_64-w64-mingw32-g++ a.cpp b.cpp -O3 -I./CBLAS/include -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a -o OMPres.exe -l gfortran -static -fopenmp
I got another error: x86_64-w64-mingw32-g++: error: libgomp.spec: No such file or directory
As I also have this file on the disk I tried to copy it in various places and finaly it worked when I copied it directly into the directory where compilation takes place. Then it produced another error:
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lgomp
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lrt
collect2: ld returned 1 exit status
I don't have a good understanding of how compilers exactly work. I tried to update all mingw-w64 compilers that I could find with apt-cache search but nothing helped. I have no idea what more I can do :(.
First, #nmaier is completely correct in that the Ubuntu x86_64-w64-mingw32 toolchain is crippled, and that you can rebuild the toolchain yourself.
I, however, suggest that you use MXE, which saves you the time of manually compiling gcc and every dependency of it. The steps below should be enough for your purpose:
# Get MXE
git clone https://github.com/mxe/mxe.git && cd mxe
# Settings
cat <<EOF > settings.mk
MXE_TARGETS := x86_64-w64-mingw32.static
JOBS := 4
EOF
# Build gcc, libgomp, blas, and cblas. It will take a while
make -j2 libgomp cblas
# Add toolchain to PATH
# See http://htmlpreview.github.io/?https://github.com/mxe/mxe/blob/master/index.html#tutorial step 4
export PATH=`pwd`/usr/bin:$PATH
# You don't need -I./CBLAS/include ./CBLAS/cblas_WIN64.a ./BLAS/blas_WIN64.a
# because headers and libraries are installed to standard location and
# I already used `-lcblas -lblas`.
x86_64-w64-mingw32-g++ a.cpp b.cpp -fopenmp -O3 -o res.exe -lcblas -lblas -lgfortran -lquadmath
Your x86_64-w64-mingw32 toolchain appears to have been build without libgomp.
You could check your supplier/distribution if it there additional or variant packages that have libgomp.
Or switch to a different supplier/distribution.
Or you could rebuild (or build in the first place) a cross gcc with --enable-libgomp. This is kinda the hard way.
PS:
Adding paths that do not correspond with your platform, like -I/usr/lib/gcc/x86_64-linux-gnu/4.6/include, is a bad idea in general, and will most certainly fail... This kinda creates a Franken-compiler.
I am trying to compile a program that uses both CUDA and OpenCV.
I am sure that the paths to OpenCV are right because compiling a simple OpenCV program with this:
cl /I"%OPENCV_DIR%\include" /LINK"%OPENCV_DIR%\x64\vc10\lib\opencv_core240.lib" "%OPENCV_DIR%\x64\vc10\lib\opencv_highgui240.lib" testCV.cpp
it successfully compiles the program. Now when I try to compile with NVCC like this:
nvcc testCuda.cu --cl-version 2010 --use-local-env -I"%OPENCV_DIR%\include" -L"%OPENCV_DIR%\x64\vc10\lib\opencv_core240.lib" "%OPENCV_DIR%\x64\vc10\lib\opencv_highgui240.lib"
I got an error when trying to link that says:
error LNK2019: unresolved external symbol cvLoadImage referenced in function main
a.exe : fatal error LNK1120: 1 unresolved externals
What am I missing or doing wrong when compiling with NVCC?
-L is used to specify library directories, not files.
You probably want to execute:
nvcc testCuda.cu --cl-version 2010 --use-local-env -I"%OPENCV_DIR%\include" -L"%OPENCV_DIR%\x64\vc10\lib" -lopencv_core240 -lopencv_highgui240
If that doens't work, drop the -l and add their extensions:
nvcc testCuda.cu --cl-version 2010 --use-local-env -I"%OPENCV_DIR%\include" -L"%OPENCV_DIR%\x64\vc10\lib" opencv_core240.lib opencv_highgui240.lib
Once upon a time, when we had CUDA 2.x and OpenCV 2.1, I wrote a Makefile to compile an application that used both frameworks:
CXX=g++
CUDA_INSTALL_PATH=/usr/local/cuda
CFLAGS= -I. -I$(CUDA_INSTALL_PATH)/include -I/usr/include/opencv
LDFLAGS= -L$(CUDA_INSTALL_PATH)/lib -lcudart -L/usr/lib -lcxcore -lcv -lhighgui -lcvaux -lml
ifdef EMU
CUDAFLAGS+=-deviceemu
endif
all:
$(CXX) $(CFLAGS) -c main.cpp -o main.o -m32 -arch i386
nvcc $(CUDAFLAGS) -c kernel_gpu.cu -o kernel_gpu.o
$(CXX) $(LDFLAGS) main.o kernel_gpu.o -o grayscale -arch i386
clean:
rm -f *.o grayscale
May be a missing -L before the second library file like the first one?
I was just able to link against cuBLAS on Windows by adding a pragma directive to my code:
#pragma comment(lib,"cublas.lib")
This might work with OpenCV as well. Be aware that this is non-portable, though.
When I run a make file in Linux to compile C codes, I get the following error:
gcc -Wall -fPIC -DSOLARIS -DXP_UNIX -DMCC_HTTPD -D_REENTRANT -I/opt/profile/OraAlert_test/code/include -I/usr/netscape/server4/plugins/include -I../../pwutils -I../../database/src -I../../access/src -I/data/share/capscan/include -o getEnv.o -c ../src/
gcc: ../src/: linker input file unused because linking not done
I have tried searching for related questions in stackoverflow and tried the the solutions suggested. Still this could not be resolved.
Any suggestions?
You have a compilation command without a source file.
What is it supposed to compile?
The error is indeed misleading. It assumes you want to link with ../src/, but -c says no linkage is to be done.
Following the instructions here I have built a Fortran enabled NDK toolchain (OSX, NDK-7b) with the goal of building LAPACK/BLAS.
Using android-cmake with the 3.4.0 net lib source it seems that I'm nearly successful. However, the BLAS build fails when linking one of the tests (with an error stating unresolved sincos and sincosf). A little searching reveals that these functions are not available in legacy Android versions. I'm wondering what is the best way to resolve these functions?
Below is and example of a linking error:
cd /Users/marc/software/lapack-3.4.0/Android/BLAS/TESTING && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/xblat2c.dir/link.txt --verbose=1
/opt/local/share/java/android-ndk-macosx/toolchains/arm-linux-androideabi-4.7.0/prebuilt/darwin-x86/bin/arm-linux-androideabi-gfortran -Wl,--gc-sections -Wl,-z,nocopyreloc -Wl,--fix-cortex-a8 -Wl,--no-undefined -lstdc++ -lsupc++ CMakeFiles/xblat2c.dir/cblat2.f.o -o ../../bin/xblat2c -rdynamic -L/Users/marc/software/lapack-3.4.0/Android/systemlibs/armeabi-v7a -L/opt/local/share/java/android-ndk-macosx/toolchains/arm-linux-androideabi-4.7.0/prebuilt/darwin-x86/user/libs/armeabi-v7a ../../lib/libblas.a -lm -Wl,-rpath,/Users/marc/software/lapack-3.4.0/Android/systemlibs/armeabi-v7a:/opt/local/share/java/android-ndk-macosx/toolchains/arm-linux-androideabi-4.7.0/prebuilt/darwin-x86/user/libs/armeabi-v7a
/opt/local/share/java/android-ndk-macosx/toolchains/arm-linux-androideabi-
4.7.0/prebuilt/darwin-x86/lib/gcc/arm-linux-androideabi/4.7.0/../../../../arm-linux-androideabi/lib/libgfortran.a(c99_functions.o): In function cexpf':
/opt/local/share/java/android-ndk-macosx/src/build/../gcc/gcc-4.7.0/libgfortran/intrinsics/c99_functions.c:910: undefined reference tosincosf'
GCC needs to know at compile time whether sincos is available or not. It does so based on the target. In case of the target triplet arm-linux-androideabi, it looks at gcc/config/linux.h and finds there:
/* Whether we have sincos that follows the GNU extension. */
#undef TARGET_HAS_SINCOS
#define TARGET_HAS_SINCOS (OPTION_GLIBC || OPTION_BIONIC)
The reason for the inclusion of Bionic is that Android 2.3 added support for sincosf/sincos/sincosl [1]. Thus, you can either update Bionic or you patch GCC to assume that no sincos is available; cf. also [2].
[1] http://source-android.frandroid.com/bionic/libc/docs/CHANGES.TXT
[2] https://bugs.launchpad.net/linaro-android/+bug/908125
While I run snmpd daemon on powerpc board(a.p.) I am getting this error:
R_PPC_REL24: Compile shared libraries with -fPIC!
/usr/local/sbin/snmpd: symbol 'strlen': can't handle reloc type 0xa in lib
/lib/libnetsnmpmibs.so.15'
sh: you need to specify whom to kill
I googled and found that the -fPIC flag should be there while compiling and its place should be right after gcc, so I changed my Makefie accordingly. Here is a snippet of my makefile:
$(Q)cd $(PROJECT_BUILD_DIR)/$(NET_SNMP_PKG) && ./configure --target=$(TARGET_TRIPLET) \
--host=$(HOST_TRIPLET) \
--build=$(BUILD_TRIPLET) \
--with-cc="$(CR_COMPLR)gcc -fPIC" \`
--with-cflags="-Os -I$(RFS)/lib -I$(NMS_DIR)/include" \`
--with-linkcc="$(CR_COMPLR)gcc -fPIC" \`
As you can see I embedded -fPIC right after gcc, but I am still getting an error. I have cross compiled for powerpc platform and I am using latest buildroot-2011.11 and gcc 4.3.6 and uClibc version 0.9.32. What may be the cause of error?
P.S. When I do nm libnetsnmpmibs.so.15 | grep strlen then I get output as U strlen. Does this mean it is undefined?
I got the problem. actually the main thing is to compile with -fPIC only.
In my case I was compiling snmp libraries with -fPIC correctly but some of the functions were dependent on libraries of other packages (nms). As I am working on firmware development there are more than 20 packages involved. So I compiled nms libraries with -fPIC and error is resolved.