On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2018-03-28 23:53, Martin Buchholz wrote:
>
> I can't find any documentation for what JNIEXPORT and friends actually do.
> People including myself have been cargo-culting JNIEXPORT and JNICALL for
> dec
On 2018-03-28 23:53, Martin Buchholz wrote:
I can't find any documentation for what JNIEXPORT and friends actually do.
People including myself have been cargo-culting JNIEXPORT and JNICALL
for decades.
Why aren't they in the JNI spec?
That surprises me. I'm quite certain that javah (or rather,
I can't find any documentation for what JNIEXPORT and friends actually do.
People including myself have been cargo-culting JNIEXPORT and JNICALL for
decades.
Why aren't they in the JNI spec?
---
It's fishy that the attribute externally_visible (which seems very
interesting!) is ARM specific.
#
Build changes still look good to me.
/Erik
On 2018-03-28 03:31, Magnus Ihse Bursie wrote:
On 2018-03-28 01:52, Weijun Wang wrote:
On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie
wrote:
https://bugs.openjdk.java.net/browse/JDK-8200193 -- for
jdk.security.auth
There is only one function t
On 2018-03-28 01:52, Weijun Wang wrote:
On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie
wrote:
https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth
There is only one function to export and it already has JNIEXPORT, so you can
just remove the new $(LIBJAAS_CFLAGS) [1].
> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie
> wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth
There is only one function to export and it already has JNIEXPORT, so you can
just remove the new $(LIBJAAS_CFLAGS) [1].
Are you going to update your webr
On 2018-03-23 17:05, mandy chung wrote:
This is a very good change and no more mapfile to maintain!!
Thank you!
Please do file JBS issues for the component teams to clean up their
exports.
I have now filed:
https://bugs.openjdk.java.net/browse/JDK-8200191 -- for java.base
https://bugs.ope
On 2018-03-23 18:24, Volker Simonis wrote:
Hi Magnus,
thanks for addressing this long standing issue! I haven't looked at
the changes, but just want to share some general and historical notes:
- Compiling with "-fvisibility=hidden" which hides all symbols expect
the ones explicitly exported wit
On 2018-03-23 18:33, Phil Race wrote:
There are a lot of changes in the desktop libraries.
Well, yes and no. While there are multiple touched files, the resulting
native shared libraries that are built have very minimal changes in
them. (That's the view point from the build guy, you know :))
On 2018-03-23 19:01, Phil Race wrote:
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html
The variable definitions here are now misaligned.
No, they are not. That's just an artifact of webrev, which
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html
The variable definitions here are now misaligned.
..and added 2d-dev since many of these native changes are in 2d.
-phil.
On 03/23/2018 10:33 AM, Ph
There are a lot of changes in the desktop libraries.
Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those since
only tier3 has any UI tests and it barely uses anything that's touched here.
So since testing seems to be wise, then I think you should do a
jtreg desktop group run on L
Hi Magnus,
thanks for addressing this long standing issue! I haven't looked at
the changes, but just want to share some general and historical notes:
- Compiling with "-fvisibility=hidden" which hides all symbols expect
the ones explicitly exported with
"__attribute__((visibility("default")))" ha
This is a very good change and no more mapfile to maintain!!
Please do file JBS issues for the component teams to clean up their
exports.
Mandy
On 3/23/18 7:30 AM, Erik Joelsson wrote:
I have looked at the build changes and they look good.
Will you file followups for each component team to
On 23/03/2018 15:15, Magnus Ihse Bursie wrote:
:
Very much so, yes. I've found a lot of dubious exports, everything from global
variables (yuck!) to functions that does not seem to be used anymore, to lots
of strange exports.
The changes looks good to me and I think we should follow this up wit
> 23 mars 2018 kl. 15:45 skrev Alan Bateman :
>
>> On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
>> With modern compilers, we can use compiler directives (such as
>> _attribute__((visibility("default"))), or __declspec(dllexport)) to control
>> symbol visibility, directly in the source code. T
On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
With modern compilers, we can use compiler directives (such as
_attribute__((visibility("default"))), or __declspec(dllexport)) to
control symbol visibility, directly in the source code. This has
historically not been present on all compilers, so w
I have looked at the build changes and they look good.
Will you file followups for each component team to look over their
exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)?
It sure looks like there is some technical debt laying around here.
/Erik
On 2018-03-23 06:56, M
With modern compilers, we can use compiler directives (such as
_attribute__((visibility("default"))), or __declspec(dllexport)) to
control symbol visibility, directly in the source code. This has
historically not been present on all compilers, so we had to resort to
using mapfiles (also known a
19 matches
Mail list logo