Reputation: 3197
yes I actually want to get that error. I am using MSVC (the command prompt). I would like to have .lib that would require definition of external symbol that gets linked to it. I must understand something wrong about static linking, because to me my approach seems legit:
I have a file that looks roughly like this:
extern INFO_BLOCK user_setup;
int
crtInit()
{
SetInfoBlock(&user_setup);
return 0;
}
when I try to use the .obj of this file in compilation with the main module
cl main.c file.obj
it says unresolved externals. That is desired behaviour.
Nevertheless, once I pack the file.obj with lib file.obj
even using /include:user_data (which frankly I don't trust as being of any use in this case)
using the .lib with cl main.c /link file.lib
does not generate missing externals and that is the problem. I need the programmer to define that symbol. Does extern get stripped away once you put your .obj in .lib? Where am I wrong?
Upvotes: 0
Views: 72
Reputation: 6063
If main.c
does not contain any reference to crtInit
there is no reason for the linker to pull that function into the generated binary - Thus it will not "see" the unresolved reference to user_setup
at all.
When you mention an object file to the linker, you force it to include the object file into the binary, regardless of whether it is needed by the program or not.
Opposed to that, when you mention a library to the linker, it will only use the library to resolve unresolved references you already have at that point with object files that it pulls in from this library. In case nothing is unresolved up to this point (or not satisfied by any symbol in the library), the linker will not use anything from the library at all.
The above is also the reason why many linkers are a bit picky about the order of libraries when linking (typically from specific to generic - or "user" to "system"), because linkers are normally single pass and will only pull in what they "see" needed at this specific point in the linking process.
Upvotes: 2