bug-libtool
[Top][All Lists]
Advanced

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

Re: [cygwin|mingw] dlpreopen and disable-static


From: Ralf Wildenhues
Subject: Re: [cygwin|mingw] dlpreopen and disable-static
Date: Mon, 26 May 2008 07:34:07 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

Hello Charles,

a couple of random thoughts:

* Charles Wilson wrote on Mon, May 26, 2008 at 12:53:28AM CEST:
>
> What is interesting is that the current transformation steps are  
> incorrect if used with EITHER the import lib or the DLL; the file  
> generated using the static library is appropriate for both static and  
> dynamic linking, assuming --enable-auto-import (and possibly  
> --enable-runtime-pseudo-reloc).

In this paragraph, does the part after ";" contradict the one before?
If not, why not?

> In the import lib case, the cyghello_2_dll_iname and  
> _head_cyghello_2_dll symbols are inappropriate; these could be solved  
> using a tag variable exclude_expsyms

OK

> (why do cygwin|mingw libtools  exclude
> "_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*"? Those are not PE
> symbols...)

For simplicity they are excluded anywhere, even though they would *need*
to be excluded (probably) only on ELF systems and/or when using GNU
tools.

> We could exclude all "^_imp__*" symbols -- or all _imp__ symbols with  
> matching _nm_s, with the understanding that a simple $global_symbol_pipe  
> can't do that -- and transform "^_nm__*" symbols into s/^_nm__//.

Yes.

> But that's only if we're using the link library, and not the DLL itself,  
> to generate the symbol list.

Why would we need to carry on symbols coming from the DLL and matching
^_imp__  ?

> But if we change the "key passage" above to  
> prefer the link library -- even if only for cygwin|mingw -- then the  
> wrong library name will be encoded as the first "import" in the  
> lt__PROGRAM__LTX_preloaded_symbols[] array:

That's bad.

> The import list currently generated from the DLL is a real mess. Just  
> running 'nm' on cyghello-0.dll gives a few interesting results:
>
> 6c641020 T _foo
> 6c6413c0 T _free
>
> _free is from cygwin1.dll, not cyghello-0.dll.  But _foo is from  
> cyghello-0.dll.

That's definitely a reason not to use the DLL, but always the import
lib.

> How do you distinguish between them? (In this case,  
> _free has a matching _imp__free, but _foo does not. Is that always the  
> case? And besides, a simple pipe can't do that sort of elimination:  
> "don't include entries for X if _imp__X exists elsewhere in the input")

I don't see why you get to the conclusion that a simple pipe can't do
that.  But anyway you are mixing up the way things are intended to work
with the apparent limitations you are seeing right now.  Don't do that.
Let's first work out how things ought to work, then see how we can
adjust the code to actually do it.  For the latter, there may be more
possibilities than are apparent.

> We could specify a very long and detailed exclude_expsyms for this case,  
> but that requires close tracking of binutils and platform-runtime  
> changes. For instance, the new binutils released *yesterday* for cygwin  
> adds new book-keeping export(s):
>
> 6c640000 A __image_base__
> 6c640000 A ___ImageBase
>
> I believe this stuff used to work, even when --disable-static.  At one  
> point, I seem to remember that some $filter included some  
> transformations with _nm_ and _imp_, but I can no longer locate that in  
> the archives or online.

Hmm.

Cheers,
Ralf




reply via email to

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