Define JNIEXPORT as visibility default with GCC?

[Jeremy Manson]

Can we just blacklist 4.1.2 explicitly?

Jeremy


On Fri, Feb 15, 2013 at 2:20 AM, David Holmes <david.holmes at oracle.com>wrote:

> On 15/02/2013 5:26 PM, Jeremy Manson wrote:
>
>> 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:
>>
>
> From the original push for 6588413 in linux gcc.make:
>
> +# version 4 and above support fvisibility=hidden (matches jni_x86.h file)
> +# except 4.1.2 gives pointless warnings that can't be disabled (afaik)
>
> So it was limited on x86 to >2 (which I think was a typo: intended to be
> >=2 or >1 ?)
>
> Of course the bsd port copied the linux file.
>
> David
>
>  http://gcc.gnu.org/wiki/**Visibility <http://gcc.gnu.org/wiki/Visibility>
>> https://developer.apple.com/**library/mac/#documentation/**
>> DeveloperTools/Conceptual/**CppRuntimeEnv/Articles/**
>> SymbolVisibility.html<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
>> <mailto:david.dehaven at oracle.**com <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-
>>
>>
>>