ld --auto-import for cygwin and libtool

Travis Howell kirben@optushome.com.au
Sun Jul 22 18:18:00 GMT 2001


I tried using that older binutils 20000722-1  again along with downgrading
the rest of Cygwin and it still works fine with data exports!
Are you sure you aren't getting the binutils versions confused ? the
announcement (
http://sources.redhat.com/ml/cygwin-announce/2000/msg00041.html ) for
20000722-1 mentions nothing much changed but the announcement (
http://sources.redhat.com/ml/cygwin-announce/2000/msg00091.html ) for
20001029 mentions several changes from dj, cgf and you.

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> >>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
>
>
>





More information about the Cygwin-apps mailing list