At 2/27/2006 12:21 AM, Brian Dessent wrote:
>This restriction (that all symbols must be resolved at link time) is a
>just a fundamental aspect of how windows works. The concept of lazy
>linking where undefined symbols can be resolved at runtime by the
>dynamic linker does not exist on windows.
Ok, great info. Are there any sources (preferably "authoritative" ones,
like from Microsoft) that I can point to for more info and future,
authoritative reference on this?
Would there be any way around this behavior, like a g++/ld parameter
option, environment variable setting, etc? (I'm guessing there is not,
especially if this is a Windows-OS restriction, but I'm leaving no stone
unturned.) As an aside: when creating the same library(ies)/DLLs (that
require the resolve-all-symbols-at-link-time problem) as static libraries
(.a files), there are no link-time symbol-resolution problems. So at least
there's some "lazy linking" capability at least on some level.
>FWIW windows is not the only platform with this restriction -- I believe
>AIX and/or darwin have similar issues. The libtool list would be able
>to give more information.
Ok. By "libtool list" I assume you mean their users email list. In any
case: would libtool help solve my above problems?
Another side (although I may take this up in more detail with the libtool
folks, but I thought it worth asking here):
I'm trying to learn more about why libtool is useful at all if it doesn't
solve the above problems. While skimming
realize: I don't need to write *any* platform-specific code for my
libraries, shared or not. Maybe this is because I'm not attempting to link
them "manually" in the code after an application's startup, I'm just
letting the linker do this for me? Is that what that stuff is all
about? (Yes, I'm quite ignorant here.)