I am using CMake to build an executable binary for a Renesas processor using GNU toolchain. I changed from object to static libraries and had issues with the interrupt table being correctly linked. Thanks to Stackoverflow I found out about --whole-archive option.
My question is, is there a linker flag or way that shows me the objects that are linked from a library so that I know which objects (so these would be the objects without unresolved symbols) the linker is ignoring?
ld can create a map file that will show which objects are linked and for what reason (i.e. which object requested the symbol to be resolved):
gcc -Wl,-Map -Wl,mapfile ...
Related
I have libA.so, libB.so, and an executable 'foo'. 'foo' needs libB.so which itself needs libA.so. During linking foo explicitly links with libB because it directly uses symbols from it. 'foo' does not directly use symbols from libA. When linking 'foo', ld wants to check it can resolve symbols references from libB in libA but it can't find libA. I can make it find libA by using -Wl,rpath-link=, or I can have the linker ignore libA using -Wl,--allow-shlib-undefined.
The problem is I shouldn't have to set either of these options because libB.so contains an rpath that tells the linker where to find libA.so and the linker uses this rpath at runtime to successfully find libA. So why doesn't it use it at link time? Forcing foo's build configuration to know where libA is seems completely unnecessary in this case?
I shouldn't have to set either of these options because libB.so contains an rpath that tells the linker where to find libA.so and the linker uses this rpath at runtime
You are mixing up the static linker ld and the runtime linker (aka loader) ld.so.
On Linux, these come from binutils and GLIBC respectively. They are completely different programs, maintained by different sets of people.
It would be possible for ld to implement the search path that current version of ld.so uses, but this is
nontrivial amount of code, that would need to be written from scratch and
will break as soon as ld.so search mechanism is changed
Update:
isn't the search of the rpath executed by the dynamic linker 'the standard'
There is no standard that defines this (that I know of).
In addition, on Linux and Solaris the search path that ld.so uses could contain dynamic tokens like $ORIGIN and $PLATFORM, which are unknown at (static) link time.
I'm trying to use pcap functions, but it giving me compiler error:
project.c:(.text+0x140): undefined reference to `pcap_open_offline'
I have installed library and while compiling I give "-lpcap" at the and as it advised in many forums.
What can be wrong, please?
You need to understand what the arguments evoke into the linker.
I am supposing you are using Linux system with gcc, using ld as linker (note that this could change depending on the system and the linker used).
In such case, -Lpath tell the linker where to look for the libraries that you tell it that are needed to be linked with your program to create the final binary. For example -L/usr/lib.
when you type in for example:
# gcc -L/usr/lib -lcap my_program.c -o my_program
You are telling the linker to append /usr/lib to the list of paths to locate libraries, and to link the dynamic library "libcap.so" with your program.
Other modifiers for the path used to locate libraries is LD_LIBRAY_PATH (the name of this environment variable could change from one system to another, review the manual of your linker).
As you are using "-lcap" the error you get look to be related with the fact that no path is found where libcap.so exist. Locate that file into your system and pass the argument
-L/path/to/the/directory/that/contain/libcap.so
By the way, try to run this before any other thing and recompile:
# sudo ldconfig
I'm trying to understand how the ELF looks like for a statically vs. a dynamically linked program.
I understand that this is how static linking works:
In my case, I have two files, foo.c and bar.c.
I also have their object files; foo.o and bar.o.
With the objdump command, I can see the relocations in each file.
How do I statically link the foo.o and bar.o?
How do I dynamically link the foo.o and bar.o?
How can I see the difference in the output files?
Linking dynamically is the default mode of most linkers these days. If you want to link statically you have to use the -static flag when linking. To clarify, when I say "linking dynamically" versus "linking statically" I mean the linking with external libraries, and not generating a library that in turn can be linked (dynamically or statically).
The difference can't be seen in the object files you pass to the linker, as it has nothing to do with the compiler and object-file generation, the result can only be seen in the resulting executable program after linking, and the biggest difference is that the executable will most likely be larger.
The resulting and fully linked executable will be larger because then all the libraries (for which there are static libraries) will actually be linked into the executable program quite literally. It's basically including the libraries object files together with your own object files. Actually, on POSIX platforms static libraries are just archives of object files.
I'm attempting to do a release of some software and am currently working through a script for the build process. I'm stuck on something I never thought I would be, statically linking LAPACK on x86_64 linux. During configuration AC_SEARCH_LIB([main],[lapack]) works, but compilation of the lapack units do not work, for example undefiend reference to 'dsyev_' --no lapack/blas routine goes unnoticed.
I've confirmed I have the libraries installed and even compiled them myself with the appropriate options to make them static with the same results.
Here is an example I had used in my first experience with LAPACK a few years ago that works dynamically, but not statically: http://pastebin.com/cMm3wcwF
The two methods I'm using to compile are the following,
gcc -llapack -o eigen eigen.c
gcc -static -llapack -o eigen eigen.c
Your linking order is wrong. Link libraries after the code that requires them, not before. Like this:
gcc -o eigen eigen.c -llapack
gcc -static -o eigen eigen.c -llapack
That should resolve the linkage problems.
To answer the subsequent question why this works, the GNU ld documentation say this:
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 libraryz' after
file foo.o but before bar.o. If bar.o refers to functions in `z',
those functions may not be loaded.
........
Normally the files found this way are library files—archive files
whose members are object files. The linker handles an archive file by
scanning through it for members which define symbols that have so far
been referenced but not defined. But if the file that is found is an
ordinary object file, it is linked in the usual fashion.
ie. the linker is going to make one pass through a file looking for unresolved symbols, and it follows files in the order you provide them (ie. "left to right"). If you have not yet specified a dependency when a file is read, the linker will not be able to satisfy the dependency. Every object in the link list is parsed only once.
Note also that GNU ld can do reordering in cases where circular dependencies are detected when linking shared libraries or object files. But static libraries are only parsed for unknown symbols once.
Like the question says: We are building on Linux using the GNU linker, and on Solaris using the solaris ld. GNU ld supports the --export-dynamic flag, which:
When creating a dynamically linked executable, add all symbols to the dynamic
symbol table. The dynamic symbol table is the set of symbols which are visible
from dynamic objects at run time.
What is the equivalent to this flag using the solaris linker? Is there an equivalent?
The Sun Studio linker (ld), by default, exports all symbols.
You can find the complete reference for the Sun linker on docs.sun.com.
Search for the "Linker and Libraries Guide".
By "all symbols" you mean all global symbols, right? C file-static symbols
are not promoted to global right? I don't think that would work.