Alexei said:
Exactly what do you mean?
Functions that are "exposed to the outer world" (external linkage) have
to be defined somewhere. They're declared in the headers, but they are
generally defined in .c files.
It shouldn't be told to. Why linking a module into executable if out of this
module nothing is referenced, neither code nor data? I'd say misleading is
gluing in unuseful code and data.
Like it or not, this behavior is common for a variety of reasons. If
you're building a library, then nearly all the code looks "unused" from
the linker's point of view.
I don't know what you mean.
The semantics of linking against static libraries and object files
differ. Generally speaking, linkers pick and choose from libraries but
include the whole of object files (unless instructed not to). Since
this is very platform-specific (and OT), I'll leave it at that.
I don't know if misleading is one of your favorite self-and-all-explanatory
words... So what if lib1 references lib2 and that one references lib1 back?
Should I get 2 copies of the same code or data (from either lib)? Is that's
what you're saying? I was replying from the size standpoint when saying
*linked once*, I meant getting one instance of say fread() in the executable
and not two or more. I don't know how exactly I should interpret this your
comment, whether you're just uncomfortable with my meaning of "linked once"
and want to tell that the linker will have to go back and forth to resolve
the undefined references in the crossreferencing libraries or want to say
something else but don't say that... If it's the former, then that's
entirely different thing here and to me it has nothing to do with the size
of the code. If it's the latter, then please explain or I'm starting to feel
that your comment is misleading at best too.
Files are often linked more than once. This is commonly known as
partial (or relocatable) linking. Mutually referential libraries need
to be repeatedly linked until there are no further unresolved symbols.
That's why your statment "each library and object file is linked only
once" is incorrect.
Understand that in most cases on non-embedded platforms, there will be
_no_ instances of library code in the executable. There will just be
an undefined symbol that is patched up by the dynamic linker/loader at
run time. To use your example, there would be no instances of fread()
in _any_ executable, one instance of fread() in a shared library, and
all executables use the same instance.
Once again, this is OT, so I will stop there.
Which means you've never been involved in projects whose size and complexity
required more horsepower for compilation than was available. Or you think
everyone's got a today's super computer. Either way this your assertion is
very doubtful.
I regularly deal with the internals of compiling and linking
multi-million line codebases, often distributed across farms of
multi-processor machines. Compilation time of large vs. small C files
do not typically differ by more than a second on any post-Pentium III
machine.
Mark F. Haigh
(e-mail address removed)