-shared option

Tue Apr 1 12:45:00 GMT 2003

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

Yes, that seems like a better idea though I would love
to know how other Java to native compilers handle this.
If I understand this correctly, we can perhaps create a new 
target macro (say) EXPORT_PUBLIC_JAVA_SYMBOL on the lines 
of MODIFY_JNI_METHOD_CALL that would be defined for MinGW 
as something like:
 #undef EXPORT_PUBLIC_JAVA_SYMBOL
 #define EXPORT_PUBLIC_JAVA_SYMBOL(DECL) \
 build_type_attribute_variant ((DECL), build_tree_list \
 (get_identifier ("dllexport"), NULL))
and the front-end would then use it like:
 /* decl is known to be ACC_PUBLIC */
 #ifdef EXPORT_PUBLIC_JAVA_SYMBOL
 decl = EXPORT_PUBLIC_JAVA_SYMBOL (decl);
 #endif
in the "appropriate" places.
After the last struggle to get MODIFY_JNI_METHOD_CALL accepted,
I'm scared of proposing new target macros so there should be 
a better way of accomplishing this. :-(
Which reminds me (OT for this thread, sorry): whatever happened 
to Mohan's strict-case-open in the front-end patch for Win32? 
Was it accepted?
Ranjit.