Re: libgcj, Win32 & dll's

[Jeff Sturm <jsturm at sigma6 dot com>]

Tom Tromey wrote:
> Alexandre> Then, there's all the dllimport/dllexport mess, that must
> Alexandre> be explicitly taken care of in user's code, which is the
> Alexandre> reason why libtool requires AC_LIBTOOL_WIN32_DLL in
> Alexandre> configure.in to build DLLs.
> 
> It seems to me that we could (in theory) modify the Java compile to
> automatically do the appropriate dllexport thing (I have no clue what
> this attribute actually does) for Java methods.  Basically it would
> just follow Java visibility rules.

Just in case you wanted to know... consider a typical reference to an
external data symbol:

  extern int foo;

  printf("foo = %d", foo);

Specifying __attribute__((dllimport)) creates an undefined symbol
_imp__foo which points to the actual global variable, i.e. doing the
equivalent of:

  extern int *_imp__foo;
  #define foo (*_imp__foo)

  printf("foo = %d", foo);

The DLL loader then performs fixups on each _imp__xxx symbol at
runtime.  A similar fixup is done for text symbols, however this can be
done transparently without the need for dllimport/dllexport.

There is apparently no way to address a global variable in a DLL without
this indirection.  Moreover, it requires knowing at compile time which
symbols will be resolved statically, and which will be in a DLL.  That's
why MSVC and GCC have the language modifiers.  Java has no similar
modifiers (and never will I hope).

> However, it sounds like this isn't sufficient, given that we want to
> export objects from the data area (e.g., vtables).  Is it really not
> possible to do what we want on Windows?  That would suck.

It sucks all right.  Suppose we added a compile-time option to gcj so
class objects are resolved at runtime.  That would avoid the DLL mess,
but the resulting code would be slightly larger and slower, I'd guess.

--
Jeff Sturm
jsturm@sigma6.com