What to do when auto-import gives the following error:

  "variable '<var>' can't be auto-imported. Please read the
  documentation for ld's `--enable-auto-import' for details."

Well, the documentation says (in part):

     This message occurs when some (sub)expression accesses an address
     ultimately given by the sum of two constants (Win32 import tables
     only allow one).  Instances where this may occur include accesses
     to member fields of struct variables imported from a DLL, as well
     as using a constant index into an array variable imported from a
     DLL.  Any multiword variable (arrays, structs, long long, etc) may
     trigger this error condition.  However, regardless of the exact
     data type of the offending exported variable, ld will always
     detect it, issue the warning, and exit.

     There are several ways to address this difficulty, regardless of
     the data type of the exported variable:
   
  See 'info ld', Invocation::Options::--enable-auto-import for ideas
  on how to deal with this problem (most often, you need to change
  your DLL's code, and your client application's code).

  Just to be clear, this "problem" is not limited to just arrays 
  and struct variables exported from a DLL.  Any multi-word data 
  type *could* exhibit the problem -- but ld will catch them, and
  report the problem with the message quoted above.  Regardless of
  the exact data type of the exported variable that triggers the 
  message, whether array or struct or long long or..., the 
  workarounds presented in the ld.info documentation will solve
  the problem for you.

The example in this directory shows how to use a local variable 
in your client code, to shadow the dll export.  With this method
there is no need to modify your DLL source code, nor do you
need to use __declspec(dllimport).  For more infomation, read the
ENTIRE --enable-auto-import section in the 'ld' documentation.

First build the example:
  
  % make

This will create usedll.exe. Run it:

  % ./usedll

You should see the following output. If not, then please report it as a
bug along with the output you *do* see.
  
dll_ll_square (3) = 9
dll_float_square (3.0) = 9.000000
dll_double_square (3.0) = 9.000000
Global long long variable: Should be 99
  directly(sortof)          : 99
  via DLL accessor function : 99
Global long long variable: Setting value to -31 directly(sortof)
Global long long variable:
  directly(sortof)          : -31
  via DLL accessor function : -31
Global long long variable: Setting value to 27 in-directly
Global long long variable:
  directly(sortof)          : 27
  via DLL accessor function : 27

If you copy broken_usedll.c onto usedll.c, you can see the "broken" 
behavior.
