Re: -shared option

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > >  > 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.

Okay.

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

AFAIK there isn't a batter way of accomplishing this.  We need to
apply pressuer to the appropriate people.

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

It was.  I guess it hasn't yet been checked in.

Andrew.