Looks good .. and worked for me when I tested with
--enable-freetype-bundling.
I used otool to verify the rpath used by fontmanager and used vmmap to
verify
an executing process was picking up freetype from the JDK's lib.
So when we do bundle freetype then it should work as expected.
-phil.
On 11/29/17, 2:48 PM, Erik Joelsson wrote:
When building macosx openjdk and enabling bundling of freetype (which
is usually not the default), the makefiles will copy the library in,
but libfontmanager will not be able to link to it at runtime. This is
caused by a peculiarity on macosx where a library that is being linked
to specifies the rpath to use in any library that links to it. At
Oracle we currently link to the libfreetype in x11 from Quartz, which
is located in /opt/X11/lib/libfreetype.6.dylib, so the libfontmanager
we build will only look in that location at runtime.
This patch adds a new build step, using the install_name_tool which
can rewrite this rpath to where you actually have a dependency on your
system. In this case right next to libfontmanager in the same
directory. I also changed the import logic that copies in libfreetype
so that it doesn't a .6 at the end on macosx.
This patch does not change the defaults for bundling of freetype, nor
does it change how Oracle bundles freetype. That may come later.
Bug: https://bugs.openjdk.java.net/browse/JDK-8139653
Webrev: http://cr.openjdk.java.net/~erikj/8139653/webrev.01/
/Erik
