The JPEG code is 2d not awt ..
Apparently the root of this problem is
> - longjmp will restore the signal mask using sigprocmask() which sets
the signal mask for the _process_.
Hmm .. so anyone using a JNI lib that uses setjmp/longjmp would have the
same issue.
Any place in the OS X libraries that end up using it would do the same ...
So I don't see how we can do a guaranteed fix here without knowing
that.The change here :-
http://cr.openjdk.java.net/~ddehaven/8026385/jdk.0/src/share/native/sun/awt/libpng/png.h.sdiff.html
is to an upstream libpng and will likely get lost when libpng is next
updated.
At the very least you will need to put some JDk specific comments here
so its
blindlingly obvious when some one updates it that they are removing our
customisation.
Alternatively, (and maybe better) is there any place that libpng looks for
any customisations you need to do ?
is
ifdef __APPLE__
something that we (JDK) define or the OS X compiler defines ?
ie if we asked to push this upstream would they want something different ?
Of course I have no idea if 'upstream' would want our behaviour anyway ..
-phil.
On 5/13/2014 12:39 PM, David DeHaven wrote:
JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8026385
Webrev:
http://cr.openjdk.java.net/~ddehaven/8026385/jdk.0/
Basically extends the work Staffan performed for
https://bugs.openjdk.java.net/browse/JDK-8023786
Verified by running:
find build/macosx-x86_64-normal-server-fastdebug/jdk/objs -name '*.o' -exec nm
-u {} \; | egrep '(setjmp|longjmp)'
With this change, all references in jdk were __setjmp or __longjmp (two
underscores), there are no remaining references to _setjmp/_longjmp in jdk with
this change.
-DrD-
