Eclipse 3.8.1 Linux Mint
Added -lm to Project / C/C++ Build / Settings / GCC C Linker / Command:
gcc -lm
Console messages:
Building target: Nicomedes
Invoking: GCC C Linker
gcc -lm -o "Nicomedes" ./Nicomedes.o
./Nicomedes.o: In function `main':
/home/bogwan/work/Nicomedes/Debug/../Nicomedes.c:244: undefined reference to `pow'
/home/bogwan/work/Nicomedes/Debug/../Nicomedes.c:258: undefined reference to `atan'
/home/bogwan/work/Nicomedes/Debug/../Nicomedes.c:260: undefined reference to `atan'
collect2: error: ld returned 1 exit status
make: *** [Nicomedes] Error 1
07:29:58 Build Finished (took 108ms)
Your linkage order is wrong. Make it gcc -o "Nicomedes" ./Nicomedes.o -lm.
In the linkage sequence, files that need symbol definitions must come before
the ones that provide the definitions. So libraries after object files.
In Eclipse, the setting C/C++ Build -> Settings -> GCC C Linker -> Command
is intended to set the program that you want to do your linking, not your linkage
options. Set library options in C/C++ Build -> Settings -> GCC C Linker -> Libraries
Related
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'm trying to make a file in Ubuntu and when i make i keep getting this error:
/usr/bin/ld: ../../gtest-1.7.0/libgtest.a(gtest-all.cc.o): undefined reference to symbol 'pthread_key_delete##GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [src/tests/run_tests] Error 1
make[1]: *** [src/tests/CMakeFiles/run_tests.dir/all] Error 2
make: *** [all] Error 2
I saw someone mentioning to go into Makefile and adding '-L /lib64 -l pthread' to the variable LDFLAGS but how do you do that? Totally new to linux here =X
The above linking problem is solved by adding
-lpthread -lm to CMakeLists.txt (target link libraries for luxrender);
TARGET_LINK_LIBRARIES(... -lpthread -lm)
I hit the same issue: -lpthread should be last in your linking invocation
(has to do with mix of static and shared symbols)
So with CMake: ${CMAKE_THREAD_LIBS_INIT} should be last. For example:
target_link_libraries(mytestlib
${BINARY_DIR}/libgmock.a
glog
gflags
${Boost_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
)
And for the OP: Search for "thread" in the CMakeLists.txt for the project your are building and paste those section (or link which project you are trying to build if it is open source) - if the above isn't self explanatory
If you are building with Make or something else, add -pthread to the compilation command line (so GCC would generate thread-safe static locals) and to the linking command line (so GCC would tell the linker to do the right thing, most notably link with -lpthread).
If you are building with CMake - then most probably you need these (full example):
# always
FIND_PACKAGE(Threads REQUIRED)
# if using boost
SET(Boost_USE_MULTITHREADED ON)
TARGET_LINK_LIBRARIES(my_app ... ${CMAKE_THREAD_LIBS_INIT})
Currently i'm working on a project to log data out of a Siemens PLC. To achieve this i'm using Snap7. Snap7 (http://snap7.sourceforge.net/) is a communication library.
I've managed to get it work on my linux desktop but when i try to cross-compile the snap7 library i get some errors
The error is generated when linking all of the object files.
g++ -shared -fPIC -o ../bin/mips-openwrt-linux-g++/libsnap7.so #"filelist.txt" -L. -lpthread -lrt -O3
/usr/bin/ld: ../temp/mips-openwrt-linux/sys_snap_msgsock.o: Relocations in generic ELF (EM: 8)
./temp/mips-openwrt-linux/sys_snap_msgsock.o: could not read symbols: File in wrong format
collect2: error: ld returned 1 exit status
make: *** [../bin/mips-openwrt-linux-g++/libsnap7.so] Error 1
If i'm correct i think it's using the wrong linker, it should use the linker of the toolchain located at: openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/bin/
I've also tried to compile the software with mips-openwrt-linux-g++.
Now another error is given:
mips-openwrt-linux-g++ -shared -fPIC -o ../bin/mips-openwrt-linux-g++/libsnap7.so #"filelist.txt" -L. -lpthread -lrt -O3
openwrt/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/../../../../mips-openwrt-linux-uclibc/bin/ld: ../temp/mips-openwrt-linux/sys_snap_msgsock.o: relocation R_MIPS_26 against `close' can not be used when making a shared object; recompile with -fPIC
../temp/mips-openwrt-linux/sys_snap_msgsock.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [../bin/mips-openwrt-linux-g++/libsnap7.so] Error 1
I hope someone is familiar with this error and can help me out.
Thanks in advance.
edit1:
There are some pre-compiled binaries. In the makefiles i changed the CC to my g++ directory. There is no LD flag so i cannot set my linker over there.
Can you cross compile and run a "hello world" program?
What is the output of file ../temp/mips-openwrt-linux/sys_snap_msgsock.o?
On ubuntu-13.04, I got an error when building an executable from shared libraries, using GCC-4.7.3 provided by the linux distribution.
I guess the problem is between libpng and zlib (the former uses the latter), but I don't know why.
First, my command is:
$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so
-lpng -lz -lpthread -lreadline -lhistory
which gives the following error:
/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread'
collect2: error: ld returned 1 exit status
But note that -lz is present. After that, I added the linker option --trace-symbol= in order to get more information:
$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so
-lpng -lz -lpthread -lreadline -lhistory -Wl,--trace-symbol=gzwrite
which in turn gives the results:
/usr/local/lib/muesli/libfml.so: reference to gzwrite
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libz.so: definition of gzwrite
/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread'
collect2: error: ld returned 1 exit status
so, gzwrite is found in libz.so but the linker don't use it!
By chance, I thought to remove the -lpng option (actually, the libpng library is not used) and my problem is solved! Why?
Secondly, I compile my whole code with another version of GCC-4.7.3 (compiled by myself -- I am used to test many versions of the compiler), and the error didn't occur, even using both -lpng and -lz!
Any idea?
In addition, a different try with another program (which USE libpng) leads to a successful build.
Edited on 2013-10-08
I'm pretty sure now that it is a bug in ubuntu-13.04: I've tried two other linux distros (Fedora 16 -- Ubuntu-10.04) and the linker behavior is standard, not as described above in the first part of my message.
I plan to report this problem on ubuntu community. Regards.
Edited on 2013-10-09
The bug has been reported to https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1237270
Two possible fixes (until ubuntu doesn't repair itself):
Try to compile in libpng.a and libz.a as a static library (it can be only a temporary solution, because static libs are evil in most cases).
Recompile libpng from the original source, and compile libz.a as static herein.
I try to build the example code provide by boost asio example:
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/example/cpp11/spawn/echo_server.cpp
I copy all the code and put it into a cpp file, compile it on linux with gcc4.7 and cmake, link with boost coroutine and boost context library, but the link is failed.
The output is list below:
Linking CXX executable ../../../output/bin/unit_test
cd /home/watson/ID_project/build/server_linux_makefile_gcc/abc/test/unit/abc_async && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/unit_test.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++11 -O3 -DNDEBUG -pthread -lrt -ltcmalloc -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free CMakeFiles/unit_test.dir/TestFileChannel.cpp.o CMakeFiles/unit_test.dir/TestStreamBuffer.cpp.o CMakeFiles/unit_test.dir/TestTimer.cpp.o CMakeFiles/unit_test.dir/TestThreadPool.cpp.o CMakeFiles/unit_test.dir/TestScheduler.cpp.o CMakeFiles/unit_test.dir/PCH.cpp.o CMakeFiles/unit_test.dir/main.cpp.o CMakeFiles/unit_test.dir/TestUDPNetwork.cpp.o CMakeFiles/unit_test.dir/TestTCPNetwork.cpp.o -o ../../../output/bin/unit_test -rdynamic ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_unit_test_framework-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_context-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_coroutine-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_thread-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_filesystem-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libyaml-cpp.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libmongoc.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_system-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libprotobuf.a
../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_coroutine-gcc47-mt-1_54.a(coroutine_context.o): In function `boost::coroutines::detail::coroutine_context::coroutine_context(void (*)(long), boost::coroutines::stack_context*)':
coroutine_context.cpp:(.text+0x103): undefined reference to `make_fcontext'
../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_coroutine-gcc47-mt-1_54.a(coroutine_context.o): In function `boost::coroutines::detail::coroutine_context::jump(boost::coroutines::detail::coroutine_context&, long, bool)':
coroutine_context.cpp:(.text+0x1bc): undefined reference to `jump_fcontext'
collect2: error: ld returned 1 exit status
make[2]: *** [abc/output/bin/unit_test] Error 1
I print the symbol table from the .a file, and find the symbol jump_fcontext' andmake_fcontext' is existed:
nm libboost_context-gcc47-mt-1_54.a
make_x86_64_sysv_elf_gas.o:
U _GLOBAL_OFFSET_TABLE_
U _exit
000000000000002e t finish
0000000000000000 T make_fcontext
jump_x86_64_sysv_elf_gas.o:
0000000000000000 T jump_fcontext
Someone can give me any tips about it? I try google every place but without information.
Try swapping the linking order of boost_context and boost_coroutine.
The linker documentation states:
[...] 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.
In this case
Boost.Coroutine depends on Boost.Context. As such, boost_coroutine should appear before boost_context when linking. For more linker ordering details, consider reading this answer.
Just to add another possibility for this (specifically with the Boost Context library) - if building under MinGW on Windows, using an earlier version of MASM can produce static libraries that contain no linkable symbols due to the way the symbols are exported.
The solution is to rebuild Boost Context with MASM 8.
See the answer at https://stackoverflow.com/a/26874113/1678468 for more about this.