Re: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
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 On 10/01/2018 02:01 PM, Phil Race wrote: On 10/1/2018 1:55 PM, Phil Race wrote: The JDK has shipped a libjpeg since, well, forever. PS .. we now call it libjavajpeg.so but that is recent (JDK 9). -phil. 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. On 10/01/2018 10:59 AM, Johan Vos wrote: 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 wrote: 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
Re: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
On 10/1/2018 1:55 PM, Phil Race wrote: The JDK has shipped a libjpeg since, well, forever. PS .. we now call it libjavajpeg.so but that is recent (JDK 9). -phil. 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. On 10/01/2018 10:59 AM, Johan Vos wrote: 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 wrote: 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
Re: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
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. On 10/01/2018 10:59 AM, Johan Vos wrote: 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 wrote: 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
Re: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
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 wrote: > 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 >
