RFR: 8349859: Support static JDK in libfontmanager/freetypeScaler.c

[Jiangli Zhou]

On Wed, 12 Feb 2025 18:37:11 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
>> 
>> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
>> 
>> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.
>
> based on the comment, perhaps the library version on the failed host is old? I suppose you can invoke the function as dynamic version with the returned pointer.

Thanks, @slowhog and @vidmik!

I notice the compilation command has `-I/usr/include/freetype2`. I think that makes sense when using system provided libfreetype and not the bundled one. If the library version on the build system is old, it probably can help explain why it cannot find the function.

So looks like we have to also call the function using the address from symbol lookup, for the static case. I was hoping that we don't have to do that, but looks like we cannot avoid.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654571311