Updated: binutils-20010802-1 (experimental)

[Christopher Faylor <cygwin at cygwin dot com>]

I've made a new version of binutils available for download.

A description of the changes to this version (courtesy of Chuck Wilson)
are included below.  There is also, for the first time, a
cygwin-specific README file in the distribution with similar wording.

Note that this version is currently experimental so you will have to
specifically select it (click on "Exp") when running setup.exe.  I
will move it from "experimental" to "current" after I've seen some
feedback (or lack thereof) on the cygwin mailing list.

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

The setup.exe program will figure out what needs to be updated on your
system and will install newer packages automatically.
 
Note that we have recently stopped downloads from sources.redhat.com
(aka cygwin.com) due to bandwidth limitations.  This means that you will
need to find a mirror which has this update.
 
In the US,
ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.
 
In Germany,
ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/
is usually pretty good.
 
In the UK,
http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/
is usually up-to-date within 48 hours.
 
If one of the above doesn't have the latest version of this package
then you can either wait for the site to be updated or find another
mirror.

If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .  I would appreciate if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

Christopher Faylor
Cygwin Engineering Manager (and Developer)
Red Hat, Inc.
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.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/