Re: -shared option

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > > what's the output file type using gcj -shared option in Windows OS?  It's
 > > just a library of objective files or a DLL file? I was confused by following
 > > examples(I don't what's type of *.so because I have no experence on
 > > UNIX/Linux :( )
 > > 
 > > gcj -shared -o swt.so ClassA.o JNIClassB.o ....
 > 
 > On Windows the output is a DLL file but is named "a.exe" by 
 > default unless you specify "-o foo.dll" explicitly.
 > 
 > However, by default, only a few symbols are exported out of
 > this DLL, namely:
 > ---------------------------- 8< --------------------------------
 > LIBRARY     FOO.DLL
 > 
 > EXPORTS
 >     JNI_CreateJavaVM              = JNI_CreateJavaVM at 12
 >     JNI_GetCreatedJavaVMs         = JNI_GetCreatedJavaVMs at 12
 >     JNI_GetDefaultJavaVMInitArgs  = JNI_GetDefaultJavaVMInitArgs at 4
 > ---------------------------- 8< --------------------------------
 > 
 > This means that you would not be able to link against your
 > "normal" Java methods using this DLL as is.
 > 
 > If you're familiar with Win32 programming, you'd know that to
 > export more symbols one can either mark the methods/variables
 > "__declspec(dllexport)" (which translates to 
 > "__attribute__(("dllexport"))" for GCC) or explicitly write a 
 > "DEF file" containing the exported symbol definitions.
 > 
 > Method attributes do not work with GCJ (or at least I do not
 > know how to use them) and I feel it might be a nice idea
 > to introduce *some* of them to GCJ (though others might
 > disagree with this).

I don't see why we need to do anything that does not correspond to
Java semantics.  In other words, symbols described as public should be
exported, and private/protected/package private ones should not.

Andrew.