Anyone who is interested in this kind of stuff is well advised to study the Linkers And Loaders book by John Levine and the compiler code of the Plan 9 operating system.
On Mar 23, 2014 12:09 PM, "David Given" <
dg@cowlark.com> wrote:
On 23/03/14 02:35, Sean Conner wrote:
[...]
> To ensure that the exectable only includes those functions used out of
> a library, you have to basically put each public routine in its own object
> file, which could explain the "lots of small files" you might see in C or
> C++.
Traditionally, yes, which is why C libraries tend to have every function
in their own source file:
http://sourceforge.net/p/tack/tack/ci/default/tree/lang/cem/libcc.ansi/ctype/toupper.c
However, the details are a bit more subtle. Linkers actually work on the
section level, not on the object file level; historically object files
could only contain a single section (I'm simplifying a bit here), so
they were equivalent.
Modern object files, however, can contain multiple sections. And modern
compilers have options to emit every function into its own section. Now
the linker is capable of discarding unused code at function granularity,
not object file granularity. Check out gcc's -ffunction-sections and
-fdata-sections options, which enable this (you may also need to pass
-Wl,--gc-sections to the linker). If you use a lot of static libraries
enabling them will probably shrink your executable considerably.
I will add that this sort of nonsense is precisely the kind of
implementation-specific detail that sane programmers[*] should never
need to care about. The fact that we *do* need to care about it is very sad.
[*] Although no-one has ever accused me of being a sane programmer.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom
