[libava/win32]: Don't add dll[im/ex]port attributes to libgcj, unless dll build

[Bryce McKinlay]

On Wednesday, Aug 6, 2003, at 16:46 Pacific/Auckland, Danny Smith wrote:

> The marking of JNI_* functions as dll[im/ex]port causes problems
> when libgcj.a is built as static lib.
>
> It seems that the JNIIMPORT and JNIEXPORT are used in two different 
> ways
> in jni.h
> 1) To declare dll linkage of functions when building or using
> libgcj itself as dll.
> 2) To declare dll linkage of functions defined in user code (eg,
> JNI_On[Un]Load). As I understand, JNIIMPORT and JNIEXPORT are 
> 'standard'
> macros that are defined in other implementations and user code expects 
> them
> to be defined in jni.h
>
> These different meanings should be separated.
>
> The following patch is ugly, but fixes the problem with static
> libgcj.a  on windows, while allowing the declaration of 
> dllimport/export
> attributes if building libgcj.as dll.

I actually prefer the .def file option discussed here: 
http://gcc.gnu.org/ml/java/2003-08/msg00076.html

Presumably libgcj.dll will want to export CNI functions as well as JNI 
functions - things like JvCreateJavaVM for example, so this 
JNI-specific solution isn't sufficient.  Using the .def file also 
cleanly defines libgcj's external interface by having it in a separate 
file, avoids cluttering up jni.h with GCJ implementation details, and 
avoids cluttering up our source with extra macros. I agree that the 
list of exported functions isn't going to change often.

Anyway, until libgcj actually works as a dll on windows, are these 
exports needed at all?

Regards

Bryce.