Temurin-build: Update build scripts with location of libfreetype.6.dylib

Created on 5 Jan 2018 · 22Comments · Source: adoptium/temurin-build

There are MANY test failures due to missing the library libfreetype.6.dylib, as described here:
https://github.com/AdoptOpenJDK/openjdk-tests/issues/136#issuecomment-355513212

Build scripts (like https://github.com/AdoptOpenJDK/openjdk-build/blob/master/makejdk.sh, makejdk-any-platform.sh, sbin/common-functions.sh) will need to be updated to refer to the actual location of this file.

The scripts are referring to the location "/Users/jenkins/workspace/openjdk_build_x86-64_macos/openjdk/installedfreetype/lib" for libfreetype.6.dylib. They should refer to jre/lib for libfreetype.6.dylib.

bug help wanted macos

Source

smlambert

👍3

All 22 comments

I've looked into this issue and found that libfreetype.6.dylib is not a run-path dependent library. As a result libfontmanager.dylib is linked with the complete install_name of library.

Bhaktavatsals-MacBook-Pro:sdk mbvreddy$ otool -L /Users/mbvreddy/workarea/JDK/OPENJ9/jdk-9+181/lib/libfontmanager.dylib 
/Users/mbvreddy/workarea/JDK/OPENJ9/jdk-9+181/lib/libfontmanager.dylib:
    @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0)
    /Users/jenkins/workspace/openjdk9_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib (compatibility version 12.0.0, current version 12.0.0)
    @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0)
    @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0)
    @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)

All other libraries part of JDK are created as run-path dependent libraries. For example libawt.dylib, libjava.dylib ...

As libfreetype.6.dylib is generated outside JDK, it is necessary to change LINKER flag -install_name /Users/jenkins/workspace/openjdk9_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib

-install_name @rpath/libfreetype.6.dylib

mbvreddy on 29 Jan 2018

I tried to see if there is any configure option in freetype-2.4.0 to change install_name to @rpath. I could not find any. Alternatively, we can use following command to change install_name of libfreetype.6.dylib

install_name_tool -id @rpath/libfreetype.6.dylib /Users/jenkins/workspace/openjdk_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib

mbvreddy on 29 Jan 2018

libfreetype.dylib.6 present in jdk/lib is not valid library on Mac. Another change is required to copy it as libfreetype.6.dylib

mbvreddy on 30 Jan 2018

@mbvreddy Thanks for doing the investigation wrt to this issue. I'll attempt to use your suggestions and get back asap.

neomatrix369 on 1 Feb 2018

@mbvreddy Can you please explain to me what you mean by this:

As libfreetype.6.dylib is generated outside JDK, it is necessary to change LINKER flag -install_name /Users/jenkins/workspace/openjdk9_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib

to

-install_name @rpath/libfreetype.6.dylib

To which app is the -install_name flag passed?

The below command:

install_name_tool -id @rpath/libfreetype.6.dylib /Users/jenkins/workspace/openjdk_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib

Does not give a feedback if it has worked or not, just returns to the prompt.

What command did you use to find the attached runpath to this dynamic library? As the path is embedded inside the binary itself.

Would be great to get answers to the above.

neomatrix369 on 1 Feb 2018

install_name_tool doesn't give any output. But you can use otool -L <library> to verify if run-path is enabled or not. It should output something like @rpath/libfreetype.6.dylib

mbvreddy on 2 Feb 2018

👍1

There is another issue to take care as mentioned in https://github.com/AdoptOpenJDK/openjdk-build/issues/202#issuecomment-361487575

mbvreddy on 2 Feb 2018

To which app is the -install_name flag passed?

inorder to change -install_name to use @rpath, we need to modify freetype makefile which doesn't seem to be feasible option here. So, I found that we could use install_name_tool to solve this issue after library is built.

mbvreddy on 2 Feb 2018

@mbvreddy thanks for all the feedback, we have used them to apply them to arrive at our fix

neomatrix369 on 6 Feb 2018

👍1

Closing as now listed in summary issue #346

smlambert on 18 Mar 2018

This bug still exists in the currently available for download OpenJDK8_x64_Mac_jdk8u172-b11.tar.gz:

Part of stacktrace when attempting to load libfontmanager.dylib:

!ENTRY org.eclipse.ui 4 0 2018-09-24 13:39:28.488
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib
  Referenced from: /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib
  Reason: image not found)

Show Java version:

$ /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java -version
openjdk version "1.8.0-adoptopenjdk"
OpenJDK Runtime Environment (build 1.8.0-adoptopenjdk-jenkins_2018_05_19_02_01-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

Show linker config for libfontmanager.dylib, linking to @rpath/libfreetype.6.dylib:

$ otool -L /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib
/Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib:
    @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0)
    @rpath/libfreetype.6.dylib (compatibility version 12.0.0, current version 12.0.0)
    @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0)
    @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0)

Show included libfreetype filename to be erroneously named as libfreetype.dylib.6

$ find /Library/Java/ -type f -name *libfreetype*
/Library/Java//JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfreetype.dylib.6

rubin55 on 24 Sep 2018

@rubin55 Yes, those binaries were produced under the old build scripts. Are you able to try a nightly build:

https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u-2018-09-24-11-44/OpenJDK8U_x64_mac_hotspot_2018-09-24-11-44.tar.gz

karianna on 24 Sep 2018

Hi @karianna , mmm still seems to be an issue there:

$ tar tvzf OpenJDK8U_x64_mac_hotspot_2018-09-24-11-44.tar.gz | grep -i freetype
-rwxr-xr-x  0 jenkins staff   696128 Sep 23 09:03 ./jdk8u181-b13/jre/lib/libfreetype.dylib.6

rubin55 on 25 Sep 2018

OK thank you.

karianna on 25 Sep 2018

Hi @karianna, as of Nov 30, this is a still a problem with the nightly build for Mac OS:

$ tar tvzf OpenJDK8U-jdk_x64_mac_openj9_2018-11-29-11-20.tar | grep -i freetype
-rwxr-xr-x  0 jenkins staff   872912 29 Nov 09:48 jdk8u192-b12/Contents/Home/jre/lib/libfreetype.dylib.6

ksilz on 30 Nov 2018

👍1

Coretto had the same issue as us: https://github.com/corretto/corretto-8/issues/6

gdams on 11 Jan 2019

Could someone provide a summary of what's going on with this bug, especially for JDK 8 please?
We thought previous PR #225 fixed it but it didn't, or the PR did resolve the issue for JDK 11, but not for JDK 8? Is there anyone working on this, if not are there something community can help? Thanks.

eed3si9n on 11 Jan 2019

@eed3si9n @ksilz @rubin55 @smlambert

Can you try the JDK/JRE at: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-mac-x64-hotspot/148/

karianna on 15 Jan 2019

@karianna I see libfreetype.6.dylib and libfreetype.dylib.6 under Contents/Home/jre/lib with slightly different file size:

-rwxr-xr-x@  1 xxx  staff    873072 Jan 15 12:38 libfreetype.6.dylib*
-rwxr-xr-x@  1 xxx  staff    873088 Jan 15 12:38 libfreetype.dylib.6*

Does that make sense?

eed3si9n on 15 Jan 2019

@karianna I see libfreetype.6.dylib and libfreetype.dylib.6 under Contents/Home/jre/lib with slightly different file size:
-rwxr-xr-x@  1 xxx  staff    873072 Jan 15 12:38 libfreetype.6.dylib*
-rwxr-xr-x@  1 xxx  staff    873088 Jan 15 12:38 libfreetype.dylib.6*
Does that make sense?

@johnoliver Is there a reasonable explanation for that? I'd have thought a copy should mean == bytes.

karianna on 16 Jan 2019

Latest nightly build OpenJDK8U-jdk_x64_mac_openj9_2019-01-21-09-29.tar.gz still shows two different files with different sizes. I think there should be only libfreetype.6.dylib:

lib  $ ls -al *freetype*
-rwxr-xr-x  1 karsten  staff  872896 21 Jan 10:24 libfreetype.6.dylib
-rwxr-xr-x  1 karsten  staff  872912 21 Jan 10:24 libfreetype.dylib.6

ksilz on 21 Jan 2019

I believe the difference in size was introduced during signing