help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ld option to retain unreferenced symbol


From: Rick
Subject: ld option to retain unreferenced symbol
Date: Wed, 14 Jan 2009 08:56:18 -0800 (PST)
User-agent: G2/1.0

Hello all.

Referring to the post below, transfered from comp.std.c++, what option
can be used on g++ or ld to retain a symbol that is not referenced?

Putting the extern in front makes it so the string appears in the .a
library, but after the linking step the string is gone from the
application.


         Regards,

         Rick


On Tue, 13 Jan 2009 18:15:32 CST, Rick <Cubs...@gmail.com> wrote in
comp.std.c++:

> My coworkers tell me that there is no way to put a string in a
> library, link with the library statically, and be able to use the
> command line utility strings to find the string in the executable
> application.  The goal is to be able to say definitively what version
> of the library was used.

> I said volatile did that; they said it didn't.  I say if you use the
> volatile keyword, you have a promise that the compiler won't discard
> the parcel of memory, even if it is never used for anything.  They say
> if you type in volatile const char version_string[] = "This is library
> StevesLibrary, version 1.23.1."; the compiler or linker optimizes it
> out.

> What does the standard say?

The C++ standard says that a namespace scope object has internal
linkage in C++, which is a change from the default external linkage in
C.

So given your:

volatile const char version_string[] = "This is library StevesLibrary,
version 1.23.1."

....if the compiler can determine that you do not access or take the
address of the character array in the translation unit, it is
perfectly acceptable for it to omit it.

On the other hand, if you override the default internal linkage with:

extern volatile const char version_string [] = /* ... */;

....than the compiler will most likely have to include it in the
object
file for that translation unit.  Depending on the tool set, the linker
may detect that it is never actually referenced and strip it from the
final executable.  Since it is never actually accessed in the program,
no strictly conforming program could tell that it was removed.

The volatile keyword does not, nor is it intended to, guarantee the
presence of anything.  Its purpose is to prevent the compiler from
performing certain optimizations on accessing (reading or writing) the
value of the object.  When there are no accesses, the keyword is
meaningless.

Your tool set may have a particular option to cause it to retain such
strings.  If that is of interest to you, consult the compiler's
documentation or ask in a compiler specific support group.

Jack Klein


reply via email to

[Prev in Thread] Current Thread [Next in Thread]