auto-import STATUS

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Now that the initial patch for auto-import has been accepted, I figured 
I should summarize the current status.  Also, for those of us who have 
to answer questions on various user lists, the two predictable FAQs are 
at the bottom of this email, with answers.  (These were inspired by 
Danny's "bug" reports <g> )

--Chuck

Auto-import BUGS/TODO:
----------------------
0. make --enable-auto-export the default (uncomment line 151
    in pe.em).  Requires 0a.) -- e.g. lots more testing.
0a. repeat all testing that was previously done with various
     in-development versions of auto-import.  Sigh.

1. make pe_data_import_dll static?
    No, used in both pe.em and pe-dll.c. But why? Is this
    really necessary -- it sure is ugly. Can we fix it?

2. Ralf's bug report.  My intuition sez this is
    related to the pe_data_import_dll thing.
    See http://sources.redhat.com/ml/binutils/2001-06/msg00742.html
    synopsis: segfaults when xmalloc returns 0.  Caused by
    running out of heap space due to memory leak (which Ralf has
    pinpointed).  Problem is, how to fix?  this bug is only user-
    visible when linking large libs.

3. Danny Smith reports an esoteric problem:
    "I am still having some (sorry, one very specific) problem
    with C++ and auto-import.  It is with cerr, cin, cout in
    the STLport of the SGI iostream lib.  These are initialised
    before main.  When building dll with auto-export and using
    auto-import to link (no dllimport attributes), I get
    successful link, but runtime failure of app at initialisation
    (before main). When building dll with --export-all, but
    marking DATA with dllimport when compiling client, I get
    successful link and run."

4. Ralf's "--export-whole-archive" problem with static libs:
    http://sources.redhat.com/ml/cygwin/2001-07/msg01198.html
    Question: how do you distinguish, automagically, between
    static libs that *shouldn't* be exported, and static
    "convenience" libs that *should* be exported?  I think
    this "problem" should be addressed at a higher level --
    for a particular package: Makefile.am?  Perhaps improvements
    to the already-experimental robert-collins-libtool?  Ralf's
    suggestion of "--export-whole-archive" and "--no-whole-archive"
    has possibilities, but it's really orthogonal to the question:
    "Does auto-import work".  (e.g. it's another feature, not an
    improvement to THIS feature).  Another possibility is to
    extend the new table-based symbol exclusion list
    (pe-dll.c(auto-export)) so that you can add patterns to those
    tables from the command line.  --exclude-symbols-from-library,
    --exclude-symbols-from-object, --exclude-symbol-with-prefix,
    --exclude-symbol-wiht-suffix  (there already is an
    --exclude-symbols option).

    But again, this is a *different* problem, not specifically a
    problem with auto-import itself.

Auto-import KNOWN ISSUES
------------------------
These behaviors are not bugs.  It's just "the way things are".

1. Situation:
      DLL: built using an "old" version of ld.  Has
           __declspec(dllexport) decorators.
      client: New client, does not use __declspec(dllimport)

    Q: Why can't I link this client with this DLL? I'm using the
    --enable-auto-import option...

    A: Because the DLL doesn't export the correct thunking items
    to allow this.  Face it, if your library headers (which
    declare function foo or variable baz) do not match the DLL,
    then you're going to have problems -- whether the discrepancy
    is "int foo()" vs. "char foo()" or "extern int foo()" vs.
    "extern __declspec(dllimport) foo()".  Clients and libs should
    AGREE on definitions!

    Ordinarily, you shouldn't have to worry about this -- if a
    library's header was munged to support DLL's the "old way" --
    that is, with appropriate defines so that __declspec(dllexport),
    __declspec(dllimport), and "" all work properly -- then they
    will continue to work.  Just read that package's documentation.

    Note also that even the "old" ld could do auto-import/export --
    if the DLL in question (a) used a functional-only interface, no
    data exports, (b) no overzealous porter (like me, csw) sprinkled
    __declspec()'s around -- THEN you could build a client app
    without __declspec's, too.  However, this ONLY works for DLL's
    written in C.  Why?  Because there aint no such animal as a C++
    dll with a functional-only interface.  C++ *has* to export data.
    Classes ARE data.

2. Situation:
      DLL: a standard, microsoft system DLL.  Generated an import
           library using dlltool, or used the import libs provided
           in the w32api package
      client: New client, accessing exported items in that DLL
           but doesn't declare them with __declspec(dllimport).

    Q: Why can't I link this client?  I'm using the
    --enable-auto-import option...

    A: Because the DLL doesn't export the correct thunking items
    to allow this -- it's an MS DLL!  This is really the same
    question as #1.  However, at least with open-source DLL's,
    it's possible (if not likely) that these old DLLs may, at
    some point in the future, be recompiled to support
    auto-import.  However, I'll give you dollars to donuts that
    MS DLL's will never support it. (Note that you CAN auto-import
    *functions* from MS DLL's -- you've been able to do that for
    several years.  It's the DATA exports that are troublesome.)

    So, you can cheat (use auto-import, be lazy with __declspec()
    on DATA items, etc)  IF and ONLY IF the dll was built by a new
    ld.  Since the official Microsoft dll's will never be built
    that way, you'll aways be stuck with these windows-isms.

    In other words, you need to "follow the __declspec rules" to
    link with MS dlls and with "old-style" dlls that were built
    with an "old" ld.  Most of the time, you won't need to worry
    about this; library maintainers and "platform distributors"
    (like the main cygwin team, or the main w32api team, will
    insure that the headers you include will use the __declspec
    decorators when necessary.  All you have to do is make sure
    to #define the appropriate flags (if any) like -DZLIB_STATIC
    on cygwin-zlib.

    Unfortunately, there will never be a replacement for reading
    the distribution documentation (or package documentation).