Mail Archives: cygwin-apps/2001/08/05/02:36:48
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--
- Raw text -