Re: Forced inclusion of "unused" objects
On Dec 8, 9:19 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Dec 8, 12:08 pm, "Bo Persson" <b...@gmb.dk> wrote:
Noah Roberts wrote:
I've found my issue and apparently it's a compiler "feature". The
linker eliminates object files that don't contain anything used,
regardless of side effects. Documented switches that you'd expect
to turn this off (like /OPT:NOREF) do not. There doesn't appear to
be a fix; if I want to force behavior to occur before main() it
simply can't be done this way--I'll have to find a way to "use"
some symbol in that object file.
That's the general idea of a library - put together a bunch of object
files and have the linker pull out the ones you need. Otherwise every
program would contain a full copy of the entire standard library!
That's the *definition* of a library. (Despite the name, DLL's
are not libraries, but object files.) If you want a specific
object file, you link the object file, or give the linker some
other explicit command to include it.
For static linking yes, but two qualms.
For *libraries* (as opposed to object files like .obj or .dll
under Windows, .o or .so under Unix).
First, for windows / unix-like systems, don't most people link to a
shared lib (aka dll) libc nowadays anyway? (I don't know much about
other systems.)
There are two issues: dynamically linking to the system is
generally necessary if you want to interface to different
versions of the system; on the other hand, you don't want to
dynamically link to anything that might not be present on the
system (isn't bundled). As far as I know, libc (the system
interface and the C runtime) has been bundled with every Unix
ever delivered, and most modern Unix don't even provide it as
a static library. In the case of Windows, I'm less sure, but it
wouldn't surprise me if the system interface and the C runtime
were separate libraries (which makes logical sense), and only
the system interface were systematically bundled.
Second, this is due to what many consider a bug in the standard. There
is an allowance in the standard which says that the namespace scope
initialization of a translation unit may be delayed until first use.
This is a piss-poor attempt at making shared libs aka dlls standard
complying. In practice, it's basically impossible for a compiler +
linker to actually delay the initialization a finite amount of time
without programmer intervention, such as during the creation of a
shared lib.
I'm not sure what you mean by the "this is due". I agree that
the permission for delayed initialization is a bug in the
standard---I've argued strongly against it more than once. But
I don't see how it affects anything here; no compiler uses this
freedom.
What is certain is that the compiler will only initialize
objects in modules which are part of the program. How you
specify which modules are part of the program is implementation
defined, but it would be a very strange (and highly undesirable)
implementation which included a module just because it happened
to appear in a library.
Unfortunately, some people got the idea that this is a cool allowance
for an optimization like the OP suggests. I'm not actually sure if
that's what the OP is hitting, but it may be. Last I heard only a
couple of obscure systems were doing it, not gcc.
I think HP experimented with it at one time. But no current
compiler does it.
Also, this doesn't automatically preclude your use case of statically
linking to a large static lib, and you only want to pull in the used
parts. That's perfectly fine. If the unused parts lack side effects,
and the compiler + linker is able to prove it, then it's fine to
remove it under the "as if" rule.
Whether the "unused" parts have side effects or not is
irrelevant. They aren't part of the program. By the definition
of "library".
I honestly don't know how hard such
analysis is. I know the Microsoft Windows Visual Studios compiler +
linker does this analysis to some degree. (Specifically, I think 2003,
2005, and/or 2008 don't report a missing member function definition if
that class is never used. Another annoying inconvenience when porting
to unix-like systems.)
Unix systems generally behave in the same manner. The C++
standard requires it: a function that isn't used need not be
defined.
Finally, is this use case all that common? How many large static libs
are there out there which you would static link to it and only want to
use a small subset of its functionality?
Most of them, I'd guess. It's pretty rare to use everything in
a library.
I'd /guess/ that either you
control the lib and can split it up, or it's some third party lib
think that's not under your control, and that sounds like it would be
a shared lib.
--
James Kanze