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

[Danny Smith <danny_r_smith_2001 at yahoo dot co dot nz>]

 --- Bryce McKinlay <bryce@mckinlay.net.nz> wrote: > 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.

I agree completely.  FWIW, I understand that MS MFC dll's use DEF file
exclusively to control dllexports.  I use a DEF file when building my own 
libstdc++.dll (Use dlltool with --export-all to get a DEF file with everything
and comment out everything except the public interface). Libobjc uses a DEF file.
With a DEF file you can also reduce bulk with NONAME keyword, so that the dll
itself does not need to store the symbol names, but relies on the import lib
to expose the names (with the STLport version of the iostream dll, this knocks off
about 600kb from the dll)  Anyway, you probably understand my bias by now.

I think that the JNIIMPORT and JNIEXPORT defines should stay for compatibility
with other implementations, but that  they do not need to be used in libgcj
itself.

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

No.  

Danny
> 

> Regards
> 
> Bryce.
>  

http://personals.yahoo.com.au - Yahoo! Personals
-  New people, new possibilities! Try Yahoo! Personals, FREE for a limited period!