> On Feb 27, 2020, at 9:59 AM, Magnus Ihse Bursie
> wrote:
>
> On 2020-02-27 15:52, Bob Vandette wrote:
>>
>>> On Feb 27, 2020, at 7:15 AM, Magnus Ihse Bursie
>>>
>>> wrote:
>>>
>>> On 2020-02-26 22:01, Bob Vandette wrote:
>>>
Here’s an updated webrev that implementes the
On 2020-02-27 15:52, Bob Vandette wrote:
On Feb 27, 2020, at 7:15 AM, Magnus Ihse Bursie
wrote:
On 2020-02-26 22:01, Bob Vandette wrote:
Here’s an updated webrev that implementes the suggestion that allows JNIEXPORT
in jni.h to be overridden
and the build limits visibility for static
> On Feb 27, 2020, at 7:15 AM, Magnus Ihse Bursie
> wrote:
>
> On 2020-02-26 22:01, Bob Vandette wrote:
>> Here’s an updated webrev that implementes the suggestion that allows
>> JNIEXPORT in jni.h to be overridden
>> and the build limits visibility for static libraries.
>>
>> If this
On 2020-02-26 22:01, Bob Vandette wrote:
Here’s an updated webrev that implementes the suggestion that allows
JNIEXPORT in jni.h to be overridden
and the build limits visibility for static libraries.
If this webrev is accepted, I’ll update the CSR solution to match this
implementation.
On 2020-02-27 00:31, David Holmes wrote:
Hi Bob,
On 27/02/2020 7:01 am, Bob Vandette wrote:
Here’s an updated webrev that implementes the suggestion that allows
JNIEXPORT in jni.h to be overridden
and the build limits visibility for static libraries.
! #if (defined(__GNUC__) && ((__GNUC__
Hi Bob,
On 27/02/2020 7:01 am, Bob Vandette wrote:
Here’s an updated webrev that implementes the suggestion that allows
JNIEXPORT in jni.h to be overridden
and the build limits visibility for static libraries.
! #if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) &&
Here’s an updated webrev that implementes the suggestion that allows JNIEXPORT
in jni.h to be overridden
and the build limits visibility for static libraries.
If this webrev is accepted, I’ll update the CSR solution to match this
implementation.
On 2020-02-26 15:56, Bob Vandette wrote:
On Feb 26, 2020, at 9:17 AM, Magnus Ihse Bursie
wrote:
On 2020-02-26 14:31, Bob Vandette wrote:
On Feb 26, 2020, at 7:31 AM, Magnus Ihse Bursie
wrote:
On 2020-02-26 08:41, David Holmes wrote:
Hi Bob,
Adding build-dev.
Thanks for noticing that
> On Feb 26, 2020, at 9:17 AM, Magnus Ihse Bursie
> wrote:
>
> On 2020-02-26 14:31, Bob Vandette wrote:
>>
>>> On Feb 26, 2020, at 7:31 AM, Magnus Ihse Bursie
>>> wrote:
>>>
>>> On 2020-02-26 08:41, David Holmes wrote:
Hi Bob,
Adding build-dev.
>>> Thanks for noticing
On 2020-02-26 14:31, Bob Vandette wrote:
On Feb 26, 2020, at 7:31 AM, Magnus Ihse Bursie
wrote:
On 2020-02-26 08:41, David Holmes wrote:
Hi Bob,
Adding build-dev.
Thanks for noticing that we were missing, David!
Sorry, I should have included you folks.
On 26/02/2020 6:37 am, Bob
Also, we've worked hard to get rid of the map files in the build system.
I'd be hesitant to say the least to re-introduce them.
/Magnus
On 2020-02-26 14:29, Bob Vandette wrote:
Thanks but I don’t like that idea for several reasons.
1. It’s too dramatic of a change for the immediate problem
Thanks but I don’t like that idea for several reasons.
1. It’s too dramatic of a change for the immediate problem I’m trying to solve.
2. It creates a support issue. Every time a new native function is added or
removed, we’d have several files
that would need to be updated (1 per OS type).
3.
> On Feb 26, 2020, at 7:31 AM, Magnus Ihse Bursie
> wrote:
>
> On 2020-02-26 08:41, David Holmes wrote:
>> Hi Bob,
>>
>> Adding build-dev.
> Thanks for noticing that we were missing, David!
Sorry, I should have included you folks.
>
>>
>> On 26/02/2020 6:37 am, Bob Vandette wrote:
>>>
Hi Bob,
On 25/02/2020 20:37, Bob Vandette wrote:
>
> Please review this RFE that alters the visibility of JNI entrypoints to
> hidden when a shared library
> is created using static JDK libraries.
As David Holmes mentions in his ocmment on the JIRA it is possible to
control re-export of the JNI
On 2020-02-26 08:41, David Holmes wrote:
Hi Bob,
Adding build-dev.
Thanks for noticing that we were missing, David!
On 26/02/2020 6:37 am, Bob Vandette wrote:
Please review this RFE that alters the visibility of JNI entrypoints
to hidden when a shared library
is created using static JDK
* Bob Vandette:
> CSR:
>
> https://bugs.openjdk.java.net/browse/JDK-8239791
For ELF (at least in the GNU incarnation), a change to the installed
jni.h is not required to make the symbols hidden; a hidden definition
would be sufficient for that. The declaration may however allow the
compiler to
Hi Bob,
Adding build-dev.
On 26/02/2020 6:37 am, Bob Vandette wrote:
Please review this RFE that alters the visibility of JNI entrypoints to hidden
when a shared library
is created using static JDK libraries.
RFE:
https://bugs.openjdk.java.net/browse/JDK-8239563
WEBREV:
Please review this RFE that alters the visibility of JNI entrypoints to hidden
when a shared library
is created using static JDK libraries.
RFE:
https://bugs.openjdk.java.net/browse/JDK-8239563
WEBREV:
http://cr.openjdk.java.net/~bobv/8239563/webrev.00/
CSR:
18 matches
Mail list logo