libgcj, Win32 & dll's

Sat Apr 1 00:00:00 GMT 2000

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