I have some trouble with the placement of the -l option when using gcc. Here's a stripped down version for reproduce the problem.
t.c:
#include <pthread.h>
int main() {
pthread_create(0, 0, 0, 0);
}
and in terminal:
$ gcc -lpthread t.c
/tmp/ccmkwV7B.o: In function `main':
t.c:(.text+0x29): undefined reference to `pthread_create'
collect2: ld returned 1 exit status
$ gcc t.c -lpthread
$ (compiles ok)
Why do I have to put -lpthread in the end to make it work? And it seems that this problem only occurs on 32bit linux.
My environment info is attached below:
gcc -lpthread t.c fails on this machine.
$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
$ uname -rm
3.0.0-12-generic i686
gcc -lpthread t.c works on this machine.
$ uname -rm
2.6.18-274.3.1.el5 x86_64
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
I looked up the gcc manual, and it says that "the placement of -l is significant". What exactly does it mean?
From the manual,
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.
This means it is very interesting that linking the library first works on gcc 4.1.2. This might have to do with the default libraries linked to by the compiler. I know on some installations I don't need to explicitly link to pthreads.
On further reflection, I think the issue is with the flag --as-needed, which may be on by default in your gcc 4.6 system. See this link for some discussion.
Related
I did not get response from Qualcomm forum so I decided to post here. When I was trying to run examples of Halide for Hexagon by running make run as written in the document. Then I got the following issue. The -lc++abi is missing.
clang++ -std=c++11 -I /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/include -stdlib=libc++ -O3 -g -fno-rtti -rdynamic conv3x3_generator.cpp /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/lib/libHalide.a /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/tools/GenGen.cpp -o /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/Examples/build/offload/hexagon_benchmarks/bin/conv3x3.generator -lz -lrt -ldl -lpthread -lm
/usr/bin/ld: cannot find -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I checked the /usr/lib and find. So it should be there?
./x86_64-linux-gnu/libc++abi.so.1.0
./x86_64-linux-gnu/libc++abi.so.1
./llvm-10/lib/libc++abi.so.1.0
./llvm-10/lib/libc++abi.so.1
Did I miss anything or make anything stupid? Thanks!
ld is your system's host linker -- that's GNU BFD ld. clang++ must be in your PATH but it's the host clang++ and not the hexagon-clang++ that would be with Halide/Hexagon tools.
I contacted the person from Qualcomm. I am not supposed to use either /usr/bin/clang++ nor hexagon-clang++. I downloaded clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz from https://releases.llvm.org/7.0.1/. You should use clang++ under the bin folder after you extract it. Now it works for me.
I want to compile the dialog program as 32-bit and statically linked executable in a 64-bit Ubuntu (16.04). This makes it easily distributable in a makeself archive without worrying about dependencies and such. I already built it 3 years ago that way and also took notes how to do it:
# get source and build-deps, then run:
./configure CFLAGS="-m32" LDFLAGS="-m32 -static"
make
Now I modified the source (added additional option) but the rebuild fails with complaints about undefined reference to Gpm_*** functions. This is unrelated to my modifications. Linking stage:
gcc -o dialog dialog.o -L. -ldialog -Wl,-rpath,/lib64 -L/lib64 -m32 -static -lncurses -ltermcap -lm
/usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/libncurses.a(lib_mouse.o): In function `_nc_mouse_event':
(.text+0x632): undefined reference to `Gpm_GetEvent'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/libncurses.a(lib_mouse.o): In function `enable_gpm_mouse':
(.text+0xcd2): undefined reference to `Gpm_Close'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/libncurses.a(lib_mouse.o): In function `enable_gpm_mouse':
(.text+0xd22): undefined reference to `Gpm_Open'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/libncurses.a(lib_mouse.o): In function `enable_gpm_mouse':
(.text+0xd3a): undefined reference to `Gpm_Close'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/libncurses.a(lib_mouse.o): In function `_nc_mouse_init':
(.text+0xe8c): undefined reference to `gpm_fd'
/usr/lib/gcc/x86_64-linux-gnu/5/../../../i386-linux-gnu/libncurses.a(lib_mouse.o): In function `mouse_activate':
(.text+0x1061): undefined reference to `gpm_fd'
collect2: error: ld returned 1 exit status
makefile:211: recipe for target 'dialog' failed
make: *** [dialog] Error 1
The linker picks up the libncurses.a which seems to be ok to me as it is a static library archive. I don't understand why the Gpm_*** functions are not found. The libgpm.a provides these and is in the same directory. Even configuring with adding /usr/lib/i386-linux-gnu/libgpm.a to the LDFLAGS has no effect.
How can I make it link successfully?
Update:
See results with verbose linking (-Wl,--verbose) here: https://pastebin.com/AP48KMGt
It works for me after installing gcc-multilib (of course) and the i386 development packages for libncurses5, libtinfo and libgpm:
sudo apt install gcc-multilib libncurses5-dev:i386 libtinfo-dev:i386 libgpm-dev:i386
and linking explicitly with them:
gcc -o dialog dialog.o -L. -ldialog -g -O2 -m32 -static -lncurses -ltinfo -lgpm -lm
I got./configure to generate a working Makefile based on your example, with
$ ./configure CFLAGS="-m32" LDFLAGS="-m32 -static" LIBS="-lgpm"
$ make
...
gcc -o dialog dialog.o -L. -ldialog -m32 -Wl,-rpath,/lib64 -L/lib64 -m32 -static -lncurses -ltermcap -lm -lgpm
The result seems to be a valid i386 executable:
$ file dialog
dialog: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=4cbdb45a86cb5e6859db8c7cbeeaaa49baf45718, not stripped
Note: I tried passing --host=i686-linux-gnu, --host=i686-pc-linux-gnu, --host=i386-linux-gnu or --host=i386-pc-linux-gnu to ./configure, but it didn't make any difference.
I have two workstations, one of them runs Debian Wheezy and has gcc 4.9.2
Second one runs RHEL 5.5, gcc version is 4.8.2
when I compile the same code with the same options:
$gcc -O3 -DNDEBUG -g -o test test.c
I get all the necessary debugging information on gcc 4.9 on Debian box, however on RHEL box objdump says:
$ objdump --debugging test
test: file format elf64-x86-64
objdump: test: no recognized debugging information
What do I do wrong?
From looking around, this appears to be a known bug or limitation in objdump:
https://bugzilla.redhat.com/show_bug.cgi?id=118383
https://sourceware.org/bugzilla/show_bug.cgi?id=6483
How can I tell if a library was compiled with -g?
Suggested workarounds are using objdump -W, readelf -w, or gcc -gstabs.
I'm trying to compile a simple test program using static OpenCV libraries that have been compiled using an ARM compiler. But when I try to compile it with the command
$arm-linux-gnueabihf-g++ `pkg-config --static opencv` -I/usr/local/include -L<path to static libary> -lopencv_imgproc -lopencv_core ARMtest2.cpp -o ARMtest2
This gives
/tmp/ccxNeUbK.o: In function main':
ARMtest2.cpp:(.text+0x8a): undefined reference tocv::Mat::ones(int, int, int)'
/tmp/ccxNeUbK.o: In function cv::Mat::~Mat()':
ARMtest2.cpp:(.text._ZN2cv3MatD2Ev[_ZN2cv3MatD5Ev]+0x20): undefined reference tocv::fastFree(void*)'
/tmp/ccxNeUbK.o: In function cv::Mat::release()':
ARMtest2.cpp:(.text._ZN2cv3Mat7releaseEv[_ZN2cv3Mat7releaseEv]+0x30): undefined reference tocv::Mat::deallocate()'
collect2: error: ld returned 1 exit status
The code itself is just some simple test code that prints a Mat type variable.
I compiled the static OpenCV library with cmake-gui. I selected UNIX Makefile and then selected 'specify options for cross-compiling' where I gave the path to the ARM (arm-linux-gnueabihf) gcc and g++ compiler. Then I unticked BUILD_SHARED_LIB so it compiled static libraries. It seemed to compile fine without errors. After that I did make & sudo make install.
I also tried it with shared libraries and that worked fine on the ARM board (once I copied the libraries to the board and exported the library path).
The static .a files landed nicely in the build folder. Apparently it can also find it when I -L link to it. I have tried reversing the order of the libraries, but to no avail.
So I'm a bit at a loss what is going wrong.
I solved it. Using the normal --static pkg-config command to compile with OpenCV libraries;
`pkg-config --libs --static opencv`
Of course I installed the static libraries also to the folder /usr/local/lib where libraries get installed first. But still i don't know what I missed in the command line I tried to use. I had a look in the config file /usr/local/lib/pkgconfig/opencv.pc
Here is whats in it:
# Package Information for pkg-config
prefix=/usr/local
exec_prefix=${prefix}
libdir=
includedir_old=${prefix}/include/opencv
includedir_new=${prefix}/include
Name: OpenCV
Description: Open Source Computer Vision Library
Version: 2.4.9
Libs: ${exec_prefix}/lib/libopencv_calib3d.so ${exec_prefix}/lib/libopencv_contrib.so ${exec_prefix}/lib/libopencv_core.so ${exec_prefix}/lib/libopencv_features2d.so ${exec_prefix}/lib/libopencv_flann.so ${exec_prefix}/lib/libopencv_gpu.so ${exec_prefix}/lib/libopencv_highgui.so ${exec_prefix}/lib/libopencv_imgproc.so ${exec_prefix}/lib/libopencv_legacy.so ${exec_prefix}/lib/libopencv_ml.so ${exec_prefix}/lib/libopencv_nonfree.so ${exec_prefix}/lib/libopencv_objdetect.so ${exec_prefix}/lib/libopencv_ocl.so ${exec_prefix}/lib/libopencv_photo.so ${exec_prefix}/lib/libopencv_stitching.so ${exec_prefix}/lib/libopencv_superres.so ${exec_prefix}/lib/libopencv_ts.a ${exec_prefix}/lib/libopencv_video.so ${exec_prefix}/lib/libopencv_videostab.so -lrt -lpthread -lm -ldl
Cflags: -I${includedir_old} -I${includedir_new}
I believe this is what is being called with the pkg-config <--something_or_other> opencv line.
And saw some other things that probably get linked when compiling -lrt -lpthread -lm -ldl Not really sure though as I tried it ina normal command line and I apparently still missed somethings.
But it worked, so didn't really bother too much with it much further :)
In your command:
*$arm-linux-gnueabihf-g++ `pkg-config --static opencv` -I/usr/local/include -L<path to static libary> -lopencv_imgproc -lopencv_core ARMtest2.cpp -o ARMtest2*
The cflags was missing.
Try with:
$arm-linux-gnueabihf-g++ `pkg-config --cflags --static opencv` -I/usr/local/include -L<path to static cross-compiled libary> -lopencv_imgproc -lopencv_core ARMtest2.cpp -o ARMtest2
Assuming here that your cross-compiled headers are saved in /usr/local/include (as you specified).
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.