[12] RFR : JDK-8203884 : Update libjpeg to version 9c

[Ambarish Rapte]

Hi All,



Please review this change for updating libjpeg7 to libjpeg9c.



Webrev: http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ -> Complete patch with changes in make files and Netbeans project files.

Webrev: http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/ -> Partial patch, updated 9c files in earlier libjpeg7 folder for ease to go through difference.



JBS: https://bugs.openjdk.java.net/browse/JDK-8203884



Regards,

Ambarish

[Johan Vos]

Unrelated to the patch, I wonder if there is a better way to include this
functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on ios, where
we build a static executable).

Is it an option to prefix the public symbols?

- Johan

Post by Ambarish Rapte
Hi All,
Please review this change for updating libjpeg7 to libjpeg9c.
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ ->
Complete patch with changes in make files and Netbeans project files.
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/
-> Partial patch, updated 9c files in earlier libjpeg7 folder for ease to
go through difference.
JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
Regards,
Ambarish

[Phil Race]

The JDK has shipped a libjpeg since, well, forever.
For a long time it did export all the symbols, but what is now probably
an even longer time, it has exported only the JNI entry points.
We can do the same here.

The JDK approach used to be tediously maintained mapfiles. But recently it
was switched to use compiler directives. The default for such a library as
libjavafx_iio.so is that symbols aren't exported, and we don't need to touch
the imported source files, just add the JNIEXPORT directive to the
declarations of
the JNI functions in the JDK's own source files which are compiled into
the library.
And of course some makefile work.

See https://bugs.openjdk.java.net/browse/JDK-8200178 and
http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html

We can do something like this for FX in a follow-on bug

Another follow-on bug opportunity, is for FX to do what JDK 11 does, which
is to defer to the system libjpeg on Linux (and Solaris, but not
relevant to FX).
So libjavafx_iio.so on Linux would become just a small entry point to the
platform JPEG library.

-phil.

Post by Johan Vos
Unrelated to the patch, I wonder if there is a better way to include this
functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on ios, where
we build a static executable).
Is it an option to prefix the public symbols?
- Johan

Post by Ambarish Rapte
Hi All,
Please review this change for updating libjpeg7 to libjpeg9c.
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ ->
Complete patch with changes in make files and Netbeans project files.
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/
-> Partial patch, updated 9c files in earlier libjpeg7 folder for ease to
go through difference.
JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
Regards,
Ambarish

[Phil Race]

Post by Phil Race
The JDK has shipped a libjpeg since, well, forever.

PS .. we now call it libjavajpeg.so but that is recent (JDK 9).

-phil.

Post by Phil Race
For a long time it did export all the symbols, but what is now probably
an even longer time, it has exported only the JNI entry points.
We can do the same here.
The JDK approach used to be tediously maintained mapfiles. But
recently it
was switched to use compiler directives. The default for such a library as
libjavafx_iio.so is that symbols aren't exported, and we don't need to touch
the imported source files, just add the JNIEXPORT directive to the
declarations of
the JNI functions in the JDK's own source files which are compiled
into the library.
And of course some makefile work.
See https://bugs.openjdk.java.net/browse/JDK-8200178 and
http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html
We can do something like this for FX in a follow-on bug
Another follow-on bug opportunity, is for FX to do what JDK 11 does, which
is to defer to the system libjpeg on Linux (and Solaris, but not
relevant to FX).
So libjavafx_iio.so on Linux would become just a small entry point to the
platform JPEG library.
-phil.

Post by Johan Vos
Unrelated to the patch, I wonder if there is a better way to include this
functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on ios, where
we build a static executable).
Is it an option to prefix the public symbols?
- Johan
On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte

Post by Ambarish Rapte
Hi All,
                 Please review this change for updating libjpeg7 to
libjpeg9c.
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ ->
Complete patch with changes in make files and Netbeans project files.
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/
->  Partial patch, updated 9c files in earlier libjpeg7 folder for
ease to
go through difference.
                 JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
Regards,
Ambarish

[Phil Race]

I filed two bugs
JDK-8211362: Restrict export of libjpeg symbols from libjavafx_iio.so
JDK-8211363: Use platform version of libjpeg on Linux

-phil

Post by Phil Race

Post by Phil Race
The JDK has shipped a libjpeg since, well, forever.

PS .. we now call it libjavajpeg.so but that is recent (JDK 9).
-phil.

Post by Phil Race
For a long time it did export all the symbols, but what is now probably
an even longer time, it has exported only the JNI entry points.
We can do the same here.
The JDK approach used to be tediously maintained mapfiles. But recently it
was switched to use compiler directives. The default for such a library as
libjavafx_iio.so is that symbols aren't exported, and we don't need to touch
the imported source files, just add the JNIEXPORT directive to the
declarations of
the JNI functions in the JDK's own source files which are compiled
into the library.
And of course some makefile work.
See https://bugs.openjdk.java.net/browse/JDK-8200178 and
http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html
We can do something like this for FX in a follow-on bug
Another follow-on bug opportunity, is for FX to do what JDK 11 does, which
is to defer to the system libjpeg on Linux (and Solaris, but not
relevant to FX).
So libjavafx_iio.so on Linux would become just a small entry point to the
platform JPEG library.
-phil.

Post by Johan Vos
Unrelated to the patch, I wonder if there is a better way to include this
functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on ios, where
we build a static executable).
Is it an option to prefix the public symbols?
- Johan
On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte

Post by Ambarish Rapte
Hi All,
                 Please review this change for updating libjpeg7 to
libjpeg9c.
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ ->
Complete patch with changes in make files and Netbeans project files.
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/
->  Partial patch, updated 9c files in earlier libjpeg7 folder for
ease to
go through difference.
                 JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
Regards,
Ambarish