[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dlpreopening for windows hosts and name of the module

From: Charles Wilson
Subject: Re: dlpreopening for windows hosts and name of the module
Date: Mon, 27 Sep 2010 00:59:47 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]