This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 dll.

I actually prefer the .def file option discussed here:

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?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]