If I have a.o, b.o, and c.o, how do I make ld link them into d.o, which is then linked into my main object file? All that I want to have happen is that all the symbols in the input files get combined into one big output file.
Found it. The -r option links files incrementally, so they can be used as input to ld.
A concatenation of .o files is called a library. You create one
with the ar library utility:
ar rvs mylib.a a.o b.o c.o
You can then link against the library:
cc main.c mylib.a
Related
Say I have a.so and b.so.
Can I produce c.so as a single shared library with all the functions exported by a and b, of course resolving all intra-dependencies (i.e. all functions of b.so called by a.so and the other way around)?
I tried
gcc -shared -Wl,soname,c.so -o c.so a.so b.so
but it doesn't work.
Same goes if I archive a.o and b.o in a.a and b.a (which shouldn't modify a.o and b.o), and do
gcc -shared -Wl,soname,c.so -o c.so a.a b.a
Thanks
Merging multiple shared libraries into one is indeed practically impossible on all UNIXen, except AIX: the linker considers the .so a "final" product.
But merging archives into .so should not be a problem:
gcc -shared -o c.so -Wl,--whole-archive a.a b.a -Wl,--no-whole-archive
In practice it is not possible.
From linker point of view, a SO library is a final product that does not contain relocation information required for linking.
If you have access to either source or object files for both libraries, it is straightforward to compile/link a combined SO from them.
Using the example from this great answer about the link order in gcc, I tried the following:
echo 'extern int b; int a = b;' > b.cpp
g++ -c b.cpp -o b.o
ar cr libb.a b.o
echo 'int b;' > d.cpp
g++ -c d.cpp -o d.o
ar cr libd.a d.o
echo 'extern int a; int main() { return a; }' > a.cpp
g++ a.cpp -o a1 d.o b.o # Works
g++ a.cpp -o a2 libd.a libb.a # Fails
If the .a file is simply an archive file containing one or several .o files, how come linking with the lib*.a files (in the wrong order, as stated in the original answer) fails, but using the .o files directly (in the same order) works?
As far as the linker is concerned, the difference between a static library and an object file
in the linkage sequence is:-
An object file is to be linked, just because it is an object file, whether or not it provides
definitions of any symbols that the executable needs. If you don't want an object
file to be linked, don't mention it to the linker.
A static library is an archive of object files that are to be extracted from the
library and linked if required, where an object file in a library is required
if and only if it provides a definition of at least one hitherto undefined
symbol that the linker has observed in an object file or library appearing earlier in
the linkage sequence.
I am attempting to build an executable from three static libraries using scons. However, even though the source files have the .cc suffix, gcc is selected to link the final executable instead of g++. The following SConstruct demonstrates this issue.
lib_a = Library('a.cc')
lib_b = Library('b.cc')
lib_c = Library('c.cc')
Program('prog',[lib_a,lib_b,lib_c])
This then output the following commands to be run.
g++ -o a.o -c a.cc
g++ -o b.o -c b.cc
g++ -o c.o -c c.cc
ar rc liba.a a.o
ranlib liba.a
ar rc libb.a b.o
ranlib libb.a
ar rc libc.a c.o
ranlib libc.a
gcc -o prog liba.a libb.a libc.a
As far as I understand, the Program builder cannot determine from suffix alone whether these libraries came from C or C++ source files, and then chooses C. I know that I could work around this by specifying that C code should be linked using g++ instead of gcc, but that feels dirty. Is there some way to tell scons that it should link this program as C++ code instead of C?
SCons tries to pick a linker, based on the suffixes of the given source files. Since you're sticking the libraries right into the Program Builder, SCons is not able to see that they stem from C++ files (they have the "*.a" extension now). That's why the "smartlink" functionality of SCons switches to its default, which is "$CC" = "gcc" in your case above.
Against this, you could restructure your build a little, and make it look more like this:
lib_a = Library('a.cc')
Program('prog', 'main.cc', LIBS=['a'], LIBPATH=['.'])
Now, SCons is able to derive the linker from the file type of "main.cc"...and correctly calls the "g++" executable (if it can be found in the current path).
I'm not advocating this (the above method should be preferred), but another option would be to simply overwrite the linker that gets used with:
Program('prog', ..., LINK='g++')
Following up on #dirkbaechle's answer, realize that main.cc doesn't have to have any content. You can leave all of your code (including main() in your libraries and just provide a blank main.cc.
One convenient way to supply a blank main.cc is Textfile():
env = Environment(tools=['default', 'textfile'])
lib_a = env.Library('a.cc')
lib_b = env.Library('b.cc')
lib_c = env.Library('c.cc')
main_cc = env.Textfile('main.cc', [])
env.Program('prog',[main_cc, lib_a,lib_b,lib_c])
This way, you don't have to add any files to your source code, since main.cc will be created when it is needed.
Say I have a libmy.a static library, and I want to know what libraries it links dynamically. Actually I need that for the following: I am gonna create a new dynamic lib say libmy2.so which will link say an .o file (object file) and the libmy.a. So I wonder what libs will load libmy2.so eventually.
Static libraries do not link other libraries, either static or dynamic.
OK, assuming two C++ files, a.cpp and b.cpp.
g++ -c a.cpp -o a.o // compile a.cpp to a.o
rm -f lib1.a // no existing lib1.a (this is not essential)
ar rvs lib1.a a.o // create library lib1.a and add a.o to it
g++ -c b.cpp -o b.o // compile b.cpp to b.o
ar rvs lib1.a b.o // ad b.o to existing lib1.a
You can obviously do any amount of copying between stages to produce the library with the name you want. You can also do
ar --help
to get the ar options which might simplify the process slightly. Frankly, it's a command I almost never use except to build static libraries from a list of objects.
on a mac, it would be
nm -m C libname.a
You can use the folllowing commands to check the contents of your static libraries:
nm -C libname.a | less
or
$ar -vt libname.a
The dynamic library will dynamically link only to those dynamic libraries which you specify with -l when building it. Static libraries are principally linking time entities representing a set of *.o files and they must be processed by linker to produce executable code so there is no requirement that all implementations must be provided when building a static library. All is set up during the final link of the target executable.
What is the difference between these two file types. I see that my C++ app links against both types during the construction of the executable.
How to build .a files? links, references, and especially examples, are highly appreciated.
.o files are objects. They are the output of the compiler and input to the linker/librarian.
.a files are archives. They are groups of objects or static libraries and are also input into the linker.
Additional Content
I didn't notice the "examples" part of your question. Generally you will be using a makefile to generate static libraries.
AR = ar
CC = gcc
objects := hello.o world.o
libby.a: $(objects)
$(AR) rcu $# $(objects)
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $#
This will compile hello.c and world.c into objects and then archive them into library. Depending on the platform, you may also need to run a utility called ranlib to generate the table of contents on the archive.
An interesting side note: .a files are technically archive files and not libraries. They are analogous to zip files without compression though they use a much older file format. The table of contents generated by utilities like ranlib is what makes an archive a library. Java archive files (.jar) are similar in that they are zip files that have some special directory structures created by the Java archiver.
A .o file is the result of compiling a single compilation unit (essentially a source-code file, with associated header files) while a .a file is one or more .o files packaged up as a library.
D Shawley's answer is good, I just wanted to add a couple of points because other answers reflect an incomplete understanding of what's going on.
Keep in mind that archive files (.a) are not restricted to containing object files (.o). They may contain arbitrary files. Not often useful, but see dynamic linker dependenciy info embedded in an archive for a stupid linker trick.
Also notice that object files (.o) are not necessarily the result of a single compilation unit. It is possible to partially link several smaller object files into a single larger file.
http://www.mihaiu.name/2002/library_development_linux/ -- search in this page for "partial"
There is one more aspect of linking against .a vs .o files: when linking, all .os passed as arguments are included in the final executable, whereas entries from any .a arguments are only included in the linker output if they resolve a symbol dependency in the program.
More specifically, each .a file is an archive comprising multiple .o files. You can think of each .o being an atomic unit of code. If the linker needs a symbol from one of these units, the whole unit gets sucked into the final binary; but none of the others are unless they too are needed.
In contrast, when you pass a .o on the command line, the linker sucks it in because you requested it.
To illustrate this, consider the following example, where we have a static library comprising two objects a.o and b.o. Our program will only reference symbols from a.o. We will compare how the linker treats passing a.o and b.o together, vs. the static library which comprises the same two objects.
// header.hh
#pragma once
void say_hello_a();
void say_hello_b();
// a.cc
#include "header.hh"
#include <iostream>
char hello_a[] = "hello from a";
void say_hello_a()
{
std::cout << hello_a << '\n';
}
// b.cc
#include "header.hh"
#include <iostream>
char hello_b[] = "hello from b";
void say_hello_b()
{
std::cout << hello_b << '\n';
}
// main.cc
#include "header.hh"
int main()
{
say_hello_a();
}
We can compile the code using this Makefile:
.PHONY = compile archive link all clean
all: link
compile:
#echo ">>> Compiling..."
g++ -c a.cc b.cc main.cc
archive: compile
#echo ">>> Archiving..."
ar crs lib.a a.o b.o
link: archive
#echo ">>> Linking..."
g++ -o main_o main.o a.o b.o
g++ -o main_a main.o lib.a
clean:
rm *.o *.a main_a main_o
and obtain two executables main_o and main_a that differ in that the contents of a.cc and b.cc where provided through two .os in the first case and through a .a in the second.
Lastly we examine the symbols of the final executables using the nm tool:
$ nm --demangle main_o | grep hello
00000000000011e9 t _GLOBAL__sub_I_hello_a
000000000000126e t _GLOBAL__sub_I_hello_b
0000000000004048 D hello_a
0000000000004058 D hello_b
0000000000001179 T say_hello_a()
00000000000011fe T say_hello_b()
$ nm --demangle main_a | grep hello
00000000000011e9 t _GLOBAL__sub_I_hello_a
0000000000004048 D hello_a
0000000000001179 T say_hello_a()
and observe that main_a is in fact lacking the unneeded symbols from b.o. That is, the linker did not suck in the contents of b.o within the archive lib.a because none of the symbols from b.cc were referenced.
You can use ar to create .a file (static library) from .o files (object files)
See man ar for details.
I believe an .a file is an archive that can contain multiple object files.