Created at:
Modified at:
ld notes
Troubleshooting
"ld terminated with signal 9 [killed]" problem
When linking, you may encounter this problem. It means that the available memory you have for linking is not enough. Try to add more RAM or swap memory.
-L and -l arguments are OK, but it still give "undefined reference"
First case:
You try to compile against a 3rd-party library, you pass -L and -l correctly but the linker still complains about "undefined reference"? It is probably because the external library was compiled with a C compiler and you are using a C++ compiler in your application.
To solve this problem, tell the linker that the library was compiled with a C
compiler, surrounding its includes with the extern "C" directive.
Here is how it looks, when trying to add Lua to a C++ application::
extern "C" {
#include <lauxlib.h>
#include <lua.h>
#include <lualib.h>
}
#include <stdio.h>
#include <string.h>Mixing C and C++ Code in the Same Program
I realized then that lua already provides a header for C++::
#include <lua.hpp>That automatically includes the extern "C" thing.
Second case:
(2011-08-12)
Have you checked whether or not the library file *really* has the symbols.
When compiling the Siesta application, with support for MPI, I got thousands of lines with the following error::
.../siesta-3.0-rc1/Src/bands.F:362: undefined reference to `__mpi__integer_s_MOD_mpi_bcast_t'So I decided to check whether or not the library that should have the symbols, really had it::
$ objdump -t Obj/MPI/libmpi_f90.a | grep bcast
0000000000003400 l .text 0000000000000000 mpi__integer_v_mp_mpi_bcast_t_??unw
0000000000000280 l .IA_64.unwind_info 0000000000000018 __udt_mpi__integer_v_mp_mpi_bcast_t_??unw
0000000000008cc0 l .text 0000000000000000 mpi__r4_v_mp_mpi_bcast_t_??unw
00000000000006a0 l .IA_64.unwind_info 0000000000000018 __udt_mpi__r4_v_mp_mpi_bcast_t_??unw
000000000000e580 l .text 0000000000000000 mpi__c4_v_mp_mpi_bcast_t_??unw
0000000000000ac0 l .IA_64.unwind_info 0000000000000018 __udt_mpi__c4_v_mp_mpi_bcast_t_??unw
0000000000013e40 l .text 0000000000000000 mpi__r8_v_mp_mpi_bcast_t_??unw
0000000000000ee0 l .IA_64.unwind_info 0000000000000018 __udt_mpi__r8_v_mp_mpi_bcast_t_??unw
0000000000019700 l .text 0000000000000000 mpi__c8_v_mp_mpi_bcast_t_??unw
0000000000001300 l .IA_64.unwind_info 0000000000000018 __udt_mpi__c8_v_mp_mpi_bcast_t_??unw
000000000001efc0 l .text 0000000000000000 mpi__logical_v_mp_mpi_bcast_t_??unw
0000000000001720 l .IA_64.unwind_info 0000000000000018 __udt_mpi__logical_v_mp_mpi_bcast_t_??unw
00000000000252c0 l .text 0000000000000000 mpi__character_v_mp_mpi_bcast_t_??unw
0000000000001b40 l .IA_64.unwind_info 0000000000000018 __udt_mpi__character_v_mp_mpi_bcast_t_??unw
000000000002b500 l .text 0000000000000000 mpi__integer_s_mp_mpi_bcast_t_??unw
0000000000001f60 l .IA_64.unwind_info 0000000000000018 __udt_mpi__integer_s_mp_mpi_bcast_t_??unw
0000000000030dc0 l .text 0000000000000000 mpi__r4_s_mp_mpi_bcast_t_??unw
0000000000002380 l .IA_64.unwind_info 0000000000000018 __udt_mpi__r4_s_mp_mpi_bcast_t_??unw
0000000000036680 l .text 0000000000000000 mpi__c4_s_mp_mpi_bcast_t_??unw
00000000000027a0 l .IA_64.unwind_info 0000000000000018 __udt_mpi__c4_s_mp_mpi_bcast_t_??unw
000000000003bf40 l .text 0000000000000000 mpi__r8_s_mp_mpi_bcast_t_??unw
0000000000002bc0 l .IA_64.unwind_info 0000000000000018 __udt_mpi__r8_s_mp_mpi_bcast_t_??unw
0000000000041800 l .text 0000000000000000 mpi__c8_s_mp_mpi_bcast_t_??unw
0000000000002fe0 l .IA_64.unwind_info 0000000000000018 __udt_mpi__c8_s_mp_mpi_bcast_t_??unw
00000000000470c0 l .text 0000000000000000 mpi__logical_s_mp_mpi_bcast_t_??unw
0000000000003400 l .IA_64.unwind_info 0000000000000018 __udt_mpi__logical_s_mp_mpi_bcast_t_??unw
000000000004d3c0 l .text 0000000000000000 mpi__character_s_mp_mpi_bcast_t_??unw
0000000000003820 l .IA_64.unwind_info 0000000000000018 __udt_mpi__character_s_mp_mpi_bcast_t_??unw
0000000000003400 g F .text 0000000000000240 mpi__integer_v_mp_mpi_bcast_t_
0000000000000000 *UND* 0000000000000000 mpi_bcast_
0000000000008cc0 g F .text 0000000000000240 mpi__r4_v_mp_mpi_bcast_t_
000000000000e580 g F .text 0000000000000240 mpi__c4_v_mp_mpi_bcast_t_
0000000000013e40 g F .text 0000000000000240 mpi__r8_v_mp_mpi_bcast_t_
0000000000019700 g F .text 0000000000000240 mpi__c8_v_mp_mpi_bcast_t_
000000000001efc0 g F .text 0000000000000240 mpi__logical_v_mp_mpi_bcast_t_
00000000000252c0 g F .text 00000000000002c0 mpi__character_v_mp_mpi_bcast_t_
000000000002b500 g F .text 0000000000000240 mpi__integer_s_mp_mpi_bcast_t_
0000000000030dc0 g F .text 0000000000000240 mpi__r4_s_mp_mpi_bcast_t_
0000000000036680 g F .text 0000000000000240 mpi__c4_s_mp_mpi_bcast_t_
000000000003bf40 g F .text 0000000000000240 mpi__r8_s_mp_mpi_bcast_t_
0000000000041800 g F .text 0000000000000240 mpi__c8_s_mp_mpi_bcast_t_
00000000000470c0 g F .text 0000000000000240 mpi__logical_s_mp_mpi_bcast_t_
000000000004d3c0 g F .text 00000000000002c0 mpi__character_s_mp_mpi_bcast_t_Those are not the *exactly* symbols I was looking for, there is something
strange... You see the .IA_64.unwind_info information just before some
symbols' names? This library was compiled for the Itanium (ia64)
architecture, not X86_64 (amd64) I'm working on.
I found another file libmpi_f90.a under the same application source
directory, used objdump to check for the symbols::
$ objdump -t Src/MPI/libmpi_f90.a | grep bcast
0000000000000d80 g F .text 0000000000000007 __mpi__character_s_MOD_mpi_bcast_t
0000000000000000 *UND* 0000000000000000 mpi_bcast_
0000000000000f90 g F .text 0000000000000007 __mpi__logical_s_MOD_mpi_bcast_t
00000000000011a0 g F .text 0000000000000007 __mpi__c8_s_MOD_mpi_bcast_t
00000000000013b0 g F .text 0000000000000007 __mpi__r8_s_MOD_mpi_bcast_t
00000000000015c0 g F .text 0000000000000007 __mpi__c4_s_MOD_mpi_bcast_t
00000000000017d0 g F .text 0000000000000007 __mpi__r4_s_MOD_mpi_bcast_t
00000000000019e0 g F .text 0000000000000007 __mpi__integer_s_MOD_mpi_bcast_t
0000000000001bf0 g F .text 0000000000000007 __mpi__character_v_MOD_mpi_bcast_t
0000000000001e00 g F .text 0000000000000007 __mpi__logical_v_MOD_mpi_bcast_t
0000000000002010 g F .text 0000000000000007 __mpi__c8_v_MOD_mpi_bcast_t
0000000000002220 g F .text 0000000000000007 __mpi__r8_v_MOD_mpi_bcast_t
0000000000002430 g F .text 0000000000000007 __mpi__c4_v_MOD_mpi_bcast_t
0000000000002640 g F .text 0000000000000007 __mpi__r4_v_MOD_mpi_bcast_t
0000000000002850 g F .text 0000000000000007 __mpi__integer_v_MOD_mpi_bcast_A much cleaner output and the symbols we are looking for. So let's link against the later library, not the former.
(Why there would be two files, with the same name but targeting different architectures I don't know. It was probably a mistake from the colleague that made the tarball for me).
glibc detected ... invalid pointer: ...
It is not exactly a linking problem, but a shared library loading problem. For now, it is in this file. (TODO: change that to a better place?)
So, if you get an error like that, gdb says nothing, backtrace is
cryptographic, check your LD_LIBRARY_PATH environment and see if the
shared libraries you are using are the correct versions that you should really
use.
I got this error when I had two versions of Qt, 4.3.4 and 4.5.1, and two compiled Qwt versions, one compiled for each Qt version. So, I had:
- Qt 4.3.4: against this I compiled and used Qwt 5.1.1
- Qt 4.5.1: against this I compiled and used Qwt 5.2.0
So, my problem was that I was compiling my application against Qt 4.3.4 and
Qwt 5.1.1, but my LD_LIBRARY_PATH environment variable points to the Qwt
5.2.0 libraries directory.