Define JNIEXPORT as visibility default with GCC?

Jeremy Manson jeremymanson at google.com
Fri Feb 15 07:26:05 UTC 2013


a) I don't know what's going on behind the scenes, but if this sounds like
a good idea to folks, can we open a bug and get the process otherwise
rolling?

b) Martin, where did the 4.2 restriction come from?  Both Apple's site and
the gcc wiki say that visibility support arrived in 4.0:

http://gcc.gnu.org/wiki/Visibility
https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html


On Thu, Feb 14, 2013 at 3:01 PM, David DeHaven <david.dehaven at oracle.com>wrote:

>
> >>>> +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) &&
> >>>> (__GNUC_MINOR__ > 2)
> >>>> +  #define JNIEXPORT     __attribute__((visibility("default")))
> >>>> +  #define JNIIMPORT     __attribute__((visibility("default")))
> >>>
> >>> The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems.  The
> conditional above excludes that.  Is this intentional?
> >>
> >> It's *is* gcc, with a LLVM backend.
> >
> > Yes, but it identifies itself as GCC 4.2, so the conditional doesn't
> fire.
>
> I assume this was not the intent and the version check is just wrong.


It may be that they deliberately stayed with gcc 4.2 to keep parity with
clang, which only supports 4.2 (or it may not, because clang supports lots
of 4.3+ features).



>
>
> > If Xcode is fine with the #define, I suggest to drop the version check
> completely.  We already do not support compiling with GCC versions which
> are so old that they lack visibility support.
>
>
> If it were Mac only, I'd agree.
>
> The same header is currently used for all "unix-like" OS's (which may
> change, if I have my way), so Solaris and Linux would also be affected.
> Most Linux distros have used gcc 4 for quite a while now, I've no idea what
> Solaris uses and embedded targets are a wild mishmash of whatever someone
> manages to cobble together, so the simpler __GNUC__ check may still be
> appropriate.
>
> -DrD-
>
>



More information about the core-libs-dev mailing list