Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
Message-ID: <3B6CE974.7040302@ece.gatech.edu>
Date: Sun, 05 Aug 2001 02:36:36 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: Some words for binutils announcement?
References: <20010804213233 DOT A6332 AT redhat DOT com>
Content-Type: multipart/mixed;
 boundary="------------000100060806050707030300"

This is a multi-part message in MIME format.
--------------000100060806050707030300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:

> I'm ready to release binutils.
> 
> Does someone (Chuck?, Robert?) want to write some descriptive words for the
> binutils announcement on what is new in this release?
> 
> cgf
> 

How's this?

--Chuck


--------------000100060806050707030300
Content-Type: text/plain;
 name="README"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="README"

Changes:

o update to more recent CVS

o now implements Paul Sokolovsky's 'auto-import' functionality:
  + All DLL's are created with special 'thunking' symbols so 
    that neither __declspec(dllexport) decorators nor .def 
    files are necessary, even for DATA exports.
    libraries only).  Older DLLs and import libs without 
    these thunking symbols can still be used, as always, 
    but (as always) still require __declspec().
  + By specifying --enable-auto-import when linking client
    applications, your client can successfully link even
    if you do not specify __declspec(dllimport) -- but only
    if the dll/import lib was built using the new binutils
    and has the appropriate thunking symbols.
  + Note that you can't use the "auto-import" feature in 
    the following cases:
    - when the import library you're trying to link with
      was built by an old ld
    - when the import library was built by dlltool
    - when you're trying to link directly with the DLL (e.g.
      without using the import lib)
  + These limitations should not be too much of a problem 
    for most "ordinary" developers -- e.g. those that want
    to compile client applications that link TO current DLLs.
    Current "DLL-ized" libraries are configured so that 
    client libs get the correct __declspec() modifiers from
    the library's headers; you shouldn't need 
    "--enable-auto-import" when linking to THEM.

o includes improved export filtering for "--export-all-symbols"
  so that certain problematic symbols are NOT actually
  exported. (This is good).

Known Issues:

o there is a memory leak we haven't been able to fix as of
  yet.  However, it is minor and only seems cause a problem
  when linking HUGE numbers of object files into a DLL.  That
  is, it doesn't seem to pop up often, and should be fine for
  most purposes.  It was deemed better to release early
  than not at all.

o One of the implications of the new auto-import feature is
  that porters of libraries (DLLs) may begin to use 
  "--export-all-symbols" more often, instead of explicitly 
  marking desired exports with __declspec(dllexport) and/or 
  using a .def file (this is the typical procedure currently).
  However, this can lead to problems if multiple DLLs in a 
  project both include the same object/static lib (libtool
  calls these "convenience libraries").  The 
  --export-all-symbols will export the same symbols in both
  DLLs, and a client executable that links both will have
  a "duplicate symbol" link error.  This is not a bug with
  auto-import, or --export-all-symbols; it's just something
  for porters to keep in mind.  We don't yet have a "clean"
  solution for it (but we didn't before, either).

Expected FAQs:

Q: "I can't link to -lfoo.  I get "symbol _nm_* undefined"  
A: "you need to recompile libfoo, or change your source code 
to use __declspec(dllimport). (You're trying to "auto-import"
from a library that was built by an old ld.  Either fix your
source code so you don't need to "auto-import", or recompile
the library with a new ld).  BTW, the original porter of 
libfoo probably fixed the libfoo include headers to do the
__declspec() definitions correctly for you; did you forget 
to -Ddefine something?  Read the porter's notes for libfoo."

Q: Now that we don't need to worry about compile-time
flags to indicate static linking or dllexport or dllimport,
doesn't that mean that we can use libtool to build
shared libraries (DLLs) just like every other Unixish 
platform?
A: Theoretically, yes. But this requires a lot of updates to
the autotools (automake, autoconf, libtool) and then each
package should be "re-tooled" to use these updated scripts.
That's a long term process, but is beginning.  In fact,
one of the prerequisites is to update autoconf to version
2.52; Cygwin's autotools was updated to that version just
a week before this binutils was released.  Be patient.


--------------000100060806050707030300--