Mail Archives: cygwin-apps/2001/07/22/12:59:59
Travis Howell wrote:
>>I don't believe that this has _ever_ been supported by cygwin. Paul
>>Sokolovsky created this hack himself.
>>
>
> I'm sure binutils-20000722-1 allowed auto importing of symbols and that was
> broken/removed in binutils-20001029-1+.
>
Nope. 20000722-1 was released after dj, cgf, and I finished up a major
round of binutils hacking. The creation of dll's from binutils had
completely bitrotted due to Mumit's year long absence. We restored it.
But we did nothing to allow auto-importing of symbols without the need
for __declspec() in the source code, for DATA exports. It is true,
however, and still IS true, that you don't REALLY need __declspec() for
FUNCTION exports. (*)
Repeat: 20000722-1 REQUIRES declspec() modifiers in the code for DATA
exports.
(*) if a dll is built with __declspec(dllexport) modifiers on functions,
then you DO need __declspec(dllimport) modifiers to link to those
functions in the dll. function-auto-import only works if both dll and
client-exe are built without decorators. AFAIK, Paul's "auto-import"
patch extends this behavior to DATA as well as functions -- but both DLL
and client-exe must be built the same way, even with Paul's patch.
My concern at the moment is: can DLL's built with Paul's binutils
interoperate with previously-linked client exe's. (ESPECIALLY:
cygwin1.dll itself!) Can client exe's linked by Paul's binutils
interoperate with earlier (pre-Paul) DLL's? That's what I'm testing
currently, along with checking out some of Robert's recent libtool
improvements that use Paul's binutils.
Oh yeah: and one final concern. Currently, folks with Windows-XP-beta
are having trouble with cygwin in general. Once cygwin actually works on
Windows-XP-[beta/rc/gold/whatever], THEN: will Paul-style DLL's be
acceptable to the windows-XP runtime linker? Paul-style DLL's *do*
slightly violate the PE spec, after all...even though the runtime
linkers on WinNT, Win2K, WinME, and Win9x all seem happy.
--Chuck
- Raw text -