Undefined symbol linking C code with static library

[Susan Abercrombie]

I have an undefined symbol warning in one of a set of C programs, each of which links to the same single object library. When linked with an equivalent shared image library, there is no such warning.

One difference I have noticed is that in all of the successful links, there was a selective search of SYS$COMMON:[SYSLIB]SYS$PUBLIC_VECTORS.EXE. The map of the link with the warning shows no reference to PUBLIC_VECTORS.EXE.

Is that difference likely significant in my undefined symbol problem? Can anyone suggest what may be going on?

[Robert Brooks_1]

What's the symbol that is not resolved?

[Susan Abercrombie]

I should have stated that the object library is not a system library.

The undefined symbol is a variable named _libGlobal__, which is declared extern in a header file included in many of the modules in the object library. It is an instance of a named typedef struct declared in the same header.

A member of the struct is used in a #define of a symbol IS_LOG_EXACT_TIME, which is referenced in a function called _LogTime. That function is defined in a module named derror.c which #includes the header.

The linker finds _LogTime, but it doesn't find _libGlobal__.

[Steven Schweda]

I got lost in that description, but in the
problem program, is _libGlobal__ ever
declared _other_ than as an extern (in the
header file)? (Perhaps in the main program?)
I'd guess that it _is_ in the non-problem
programs.

alp $ type a1.c

#include

extern int ext; /* Pretend that this is in a header file. */

extern int a2( void);

main()
{
ext = 1;
printf( " ext = %d. A2 says %d.\n", ext, a2());

}


alp $ type a2.c

extern int ext; /* Pretend that this is in a header file. */

int a2()
{
return ext;
}


alp $ cc a1
alp $ cc a2
alp $ link a1, a2
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, EXT
%LINK-W-USEUNDEF, undefined symbol EXT referenced
in psect $LINK$ offset %X00000028
in module A1 file ALP$DKA0:[SMS]A1.OBJ;3
%LINK-W-USEUNDEF, undefined symbol EXT referenced
in psect $LINK$ offset %X00000010
in module A2 file ALP$DKA0:[SMS]A2.OBJ;2


alp $ type a3.c

int ext; /* Note: NOT extern. */

alp $ cc a3
alp $ link a1, a2, a3

alp $ r a1
ext = 1. A2 says 1.


It's not enough to say "extern int ext;"
everywhere. _Someone_ needs to declare
"ext" simply, to get some storage allocated
for it. In real life, no one would be likely
to declare "ext" in its own module this way,
but it does need to be declared _somewhere_.

In other words, "extern" tells the linker
that it exists elsewhere, but someone,
somewhere, needs to take responsibility and
actually make the thing.

Or else I misunderstand this whole thing.

[Susan Abercrombie]

Yes, it's easy to get lost in...

The variable itself is declared in BASE, a module in the object library, but not in the module DERROR which contains the function in which the linker reports the undefined symbol. It is never declared in the programs I'm compiling and linking with the library.

I have been scanning maps and listings, and noticed that there is nothing in the offending program which calls any function within BASE. There *is* a call to one or more functions in BASE in all the other programs.

The header makes the variable extern, and is included wherever there is any reference to the variable (either explicitly or via #defined symbols), including BASE.

There is no problem when I link to a shared image version of the library rather than the object library. The symbol_vector list for the shared image library link contains only functions.

I don't see why a function reference within BASE should be required in order to access an extern variable declared with file scope in BASE. But that seems to be so. If I insert such a reference into the problem program, the problem goes away.

What am I missing? (Besides my mind ;-)

[Steven Schweda]

> I don't see why a function reference
> within BASE should be required in order to
> access an extern variable declared with
> file scope in BASE.

Something has to get that module into the
executable, or else the storage for the
extern thing will not make it in.

I assume that you could link using something
like:

link [...] -
lib_with_base.olb /library /include = base -
[...]

which should pull in the module without
requiring some dummy function reference.

I don't do much with shared images, but I
assume that they're loaded all-or-nothing,
while, with an object library, the linker
pulls out only the pieces which it (thinks
that it) needs.

[Susan Abercrombie]

That's probably pretty convoluted, too. Let me try again.

GLOBAL.h contains
typedef struct _libGlobal
{ ... } _libGlobalRec, *_libGlobal;
extern _libGlobalRec _libGlobal__;
#define IS_LOG_EXACT_TIME (__libGlobal__.debug & (2 << 0)

MYLIB.olb contains
BASE.obj
#include "global.h"
_libGlobalRec _libGlobal__; /* file scope */


DERROR.obj
#include "global.h"
void _LogTime(FILE *fd, char *buf)
{ if (IS_LOG_EXACT_TIME) ... }

A program which does not call any function within BASE.obj in the library, but which does call stuff which calls stuff which calls _LogTime in DERROR.obj, gets an undefined symbol warning on _libGlobal__.

Add a call to any (I'm guessing -- I've tried three) function from BASE.obj and the problem goes away.

Why?

[Susan Abercrombie]

Hi Steven,

My attempt to clarify crossed with your last reply.

> Something has to get that module into the
> executable, or else the storage for the
> extern thing will not make it in.

> I assume that you could link using something
> like:

> link [...] -
> lib_with_base.olb /library /include = base -
> [...]

> which should pull in the module without
> requiring some dummy function reference.

I assumed (apparently incorrectly) that the compiler would generate a list (so to speak) of anything declared extern and created within a module, and the linker would use that (either from the .obj or from the module in the library) and thus be able to resolve any function or any external thing.

This code exists on various platforms. The problem is not observed on the other operating systems. It's mine alone, so to speak.

Thanks for your help!

Sue

[Steven Schweda]

Because the only real storage for
_libGlobal__ is declared/allocated in
BASE.obj. If the linker does not get
BASE.obj out of MYLIB.olb (and into your
executable), then your executable will not
get that storage. Hence, UDFSYM.

Refering to _libGlobal__ one more time (as
in IS_LOG_EXACT_TIME) does not get BASE.obj
into the executable.

> Add a call [...] and the problem goes away.

Yes, because that _will_ get BASE.obj into
the executable. (As will "/include = base"
in the LINK command.)


This says that it exists somewhere:
extern _libGlobalRec _libGlobal__;

So everyone believes (at compile time) that
it exists somewhere.


This makes it exist:
_libGlobalRec _libGlobal__; /* file scope */

but that's in BASE.obj, so if BASE.obj is not
linked in, then the storage for _libGlobal__
does not exist in your executable.


Now, if you want the storage to exist without
bringing in BASE.obj, you'll need to declare
_libGlobal__ somewhere else. (But if you
link together two modules which declare the
thing, then get ready for a MULDEF.)

[Steven Schweda]

This may be related to something like "weak"
versus "strong" references, or some other
topic about which I never read in the linker
manual. I would not be surprised if there
were some clever way to persuade the linker
to create this stuff the way you expected it
to happen, but I always do it the way I've
suggested (which also seems to work on UNIX
systems).

Everything's complicated, I always say.

[Steven Schweda]

Besides, if someone allocated the storage for
you automatically, and you really wanted it
to have some fancy attributes (volatile,
__restrict, __unaligned, or whatever), you'd
(silently) get what you didn't want, and
you might never guess what went wrong. (And,
more important, whom to blame.)

Yes, I'm sure that this is the best of all
possible worlds.

[Susan Abercrombie]

Well, it's VMS, so it *has* to be the best of all possible worlds, right?

The problem (that is to say, the link warning) doesn't happen on our unix platforms. From which fact I am informed by my peers that there is something wrong with the way VMS does it.

Thanks very much!

Sue

[Steven Schweda]

Tell 'em that _properly_ structured code
_does_ work the same everywhere. They
probably won't believe it, but you have my
permission to look very smug as you say it.

[Steven Schweda]

Also, it's worse than just a LINK warning.
The program will ACCVIO at run time:

alp $ link a1, a2
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, EXT
%LINK-W-USEUNDEF, undefined symbol EXT referenced
in psect $LINK$ offset %X00000028
in module A1 file ALP$DKA0:[SMS]A1.OBJ;3
%LINK-W-USEUNDEF, undefined symbol EXT referenced
in psect $LINK$ offset %X00000010
in module A2 file ALP$DKA0:[SMS]A2.OBJ;2

alp $ run a1
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000
0000, PC=00000000000200CC, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
A1 A1 main 1600 00000000000000CC 00000000000200CC
A1 A1 __main 1598 0000000000000064 0000000000020064
0 FFFFFFFF80269ED4 FFFFFFFF80269ED4
alp $

Because, of course, we don't know where that
extern thing is supposed to be ("VA = 0").

[Susan Abercrombie]

In this particular case, I think the probability of _LogTime actually being executed is very small indeed. However, I absolutely agree that this needs to be fixed with _properly_ structured code.

User code doesn't know or care about _libGlobal__, so it doesn't want to be declared in anybody's main routine. The fix should be done within the library.

I know nothing of the structure of unix static libraries, so I have no clue what unix does with this situation.

I assumed that ACCVIO would be the result if the function that uses _libGlobal__ actually executed. I did not try to set up an execution scenario that might make it happen.

Again, thanks very much! I will need to figure out how to go about rating solutions!

[Ian Miller.]

Re points see
http://forums1.itrc.hp.com/service/forums/helptips.do?#33

I think Simon has covered it. I am told that on unix you can get away with this i.e lots of references but no definition. On VMS you have to declare it once somewhere. You could use the /INCLUDE=BASE.OBJ qualifier on the LINK paramter that specifies the library to force the inclusion of the object mode that defines the variable.

The extern model specified to the compiler also influences this. RTF for the gory details.

On VMS I64 the rules are different.

[Volker Halle]

Susan,

please let me forward some comments (from an informed source):


On VMS I64 the rules are different.


No.

Without the actual the link command and the options file, this is unlikely to be resolved in this stream.


I have an undefined symbol warning in one of a set of C programs, each of which links to the same single object library. When linked with an equivalent shared image library, there is no such warning.


The order of processing the input files is probably different in both cases. The linker manual in chapter 2 explains how symbol resolution works.


The problem (that is to say, the link warning) doesn't happen on our unix platforms. From which fact I am informed by my peers that there is something wrong with the way VMS does it.


So ask the unix guys to produce a linker map. Then you will see the object module which defines the symbol. Explicitly include that module in your link command and you are done.

Volker.

PS: Just the messenger...