-shared option

[Ranjit Mathew]

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