Re: DLL and external references
From: William DePalo [MVP VC++] (willd.no.spam_at_mvps.org)
Date: 07/15/04
- Next message: alias.name: "Re: DLL and external references"
- Previous message: Igor Tandetnik: "Re: Creating a pointer to an array of structs"
- In reply to: alias.name: "DLL and external references"
- Next in thread: alias.name: "Re: DLL and external references"
- Reply: alias.name: "Re: DLL and external references"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 15 Jul 2004 14:46:59 -0400
"alias.name" <alias.name@gmail.com> wrote in message
news:Xns9527735735581aliasnamegmailcom@207.217.125.205...
> This is probably a basic question:
It is.
> When linking I do NOT specify the static library in which
> "external_function" exists in.
>
> This causes a linker error "extern int external_function()" unresolved
> external.
>
> The question is, do all external references in a DLL have to be resolved
at
> link time?
Short answer: Yes because you are using an "implicit" linking mechanism
Longer answer: Yes, but you can do better if necessary.
The issue is that your code makes an explicit reference to a function
external to the compilation unit. The compiler marks it as such. In the
world before DLLs, it was the job of the linker to "resolve" external
references and "bind" them to addresses by adding object code from external
sources (libraries and other compiled objects) to the executable image.
This behavior of the compiler doesn't change when DLLs are present. Adding
the the DLL's import library resolves all the references to each imported
function to a single address which contains a jump instruction whose target
is left blank. This unresolved reference is called an "import". At load
time, Windows maps the DLLs that you reference into your process, notes the
addresses of all of the (possibly relocated) imported functions contained in
the DLLs and then patches the import table so those jump instructions are
not jumps to nowhere.
With that simplified explanation, you can see if you don't supply an import
library for the DLL that you will have unresolved references. That's a
no-no.
There are at least two ways to defer the resolution of imports until
runtime. One is to call the DLL functions via pointers. You can get the
pointer to a function by calling LoadLibrary() followed by GetProcAddress().
The other way is to let the compiler and linker do this for you, it is
called delay loading.
Both techniques, have their place. But for now, I think you should go with t
he simple answer. :-)
Regards,
Will
- Next message: alias.name: "Re: DLL and external references"
- Previous message: Igor Tandetnik: "Re: Creating a pointer to an array of structs"
- In reply to: alias.name: "DLL and external references"
- Next in thread: alias.name: "Re: DLL and external references"
- Reply: alias.name: "Re: DLL and external references"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
