Re: dlpreopening for windows hosts and name of the module

[Charles Wilson]

On 9/26/2010 2:58 PM, Roumen Petrov wrote:
> The libtool manual describe dlpreopening and details structure of
> preloaded_symbols.
> 
> The current test "enforced lib prefix"(need_lib_prefix.at) pass on
> windows host as modules are build without -no-undefined flag.

I don't have time to look further in to this before next weekend, but I
don't believe your solution is correct; we've already been thru several
iterations of precisely this issue.

If the modules are built using -no-undefined, then you DO have .dll
modules with associated .dll.a import libraries.  Even if you -dlpreopen
them, all that does is link against the import library (unless you also
add -static or -all-static); thus, the ACTUAL name of the library that
you would be opening (which is already loaded by the Windows Runtime
Loader) is the .dll, not the .a.

So, if there is a problem with this configuration, I don't think it is
because the symbols[] table has the "wrong" library name in it; there
must be some other problem -- like why the .dll can't be opened, even
though it is already in memeory.

--
Chuck