1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
1) C++ ABI
The C++ ABI generated by GCC version 2.95, 2.96, 3.0, and 3.1.1 are
incompatible with each other. This means that, for examples, apps compiled
with GCC 2.95 cannot link to libraries compiled with GCC 3.2.
GCC 3.4 is the latest ABI at the moment (April 2005). But the most widely
used ABI at the moment is the GCC 3.2 ABI.
2) Symbol collisions, be aware of what libraries are implicitly linked in.
Imagine the following situation:
- foo contains the symbol foobar (a function).
- libbar contains a symbol with the same name, but is a totally different
function.
- foo is linked to libbar.
When foo tries to call foobar(), it's undefined whether it will call the
foobar() from it's own binary, or the one from libbar. Depending on what
those functions do, foo may crash or do something it isn't supposed to do.
Solution: rtld features, -Bgroup. However, at this moment these are not
supported by glibc. Until they are, keep these in mind:
- You should mark all functions that you do not want to export (or show up
in the symbol table) as static.
- If you're a library, you should namespace all functions.
- Internal functions that are used within a library, but across multiple
.c files, should be prefixed by a _ or __.
3) Linking against shared versions of X11 extension libs
Some X libraries, such as libXrender, are originally not shared libraries.
Distributions just created shared library versions to save memory. So
some distributions don't ship the shared versions at all. Apbuild
automatically statically links some of those X libraries (you can turn
this behavior off of course).
4) Usage of sys_errlist
5) Don't use TLS (the __thread keyword).
|
