temurin-build: LinkError on GUI apps on MacOS

From @helenmasters on September 5, 2017 13:7

We are seeing an issue on OSX when we try to run any GUI applications. It looks as though /Users/jenkins/workspace is hardcoded so cannot be resolved on the user’s machine.

Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib: dlopen(/Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib, 1): Library not loaded: /Users/jenkins/workspace/openjdk_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib
  Referenced from: /Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib
  Reason: image not found
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1122)
	at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:93)
	at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:80)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.lwawt.macosx.LWCToolkit.<clinit>(LWCToolkit.java:79)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)
	at java.awt.Toolkit$2.run(Toolkit.java:860)
	at java.awt.Toolkit$2.run(Toolkit.java:855)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)
	at javax.swing.UIManager.getSystemLookAndFeelClassName(UIManager.java:611)
	at javax.swing.UIManager$1.run(UIManager.java:1233)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.swing.UIManager.loadSwingProperties(UIManager.java:1228)
	at javax.swing.UIManager.initialize(UIManager.java:1457)
	at javax.swing.UIManager.maybeInitialize(UIManager.java:1426)
	at javax.swing.UIManager.getUI(UIManager.java:1006)
	at javax.swing.JPanel.updateUI(JPanel.java:126)
	at javax.swing.JPanel.<init>(JPanel.java:86)
	at javax.swing.JPanel.<init>(JPanel.java:109)
	at javax.swing.JPanel.<init>(JPanel.java:117)
	at citmsxa.<init>(citmsxa.java:11)
	at citmsxa.main(citmsxa.java:376)

Here is the output from the otool command suggesting that the path is incorrect…

helens-mbp:check helenmasters$ otool -L /Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib
/Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib:
	@rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0)
	/Users/jenkins/workspace/openjdk_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)
	/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)

Copied from original issue: AdoptOpenJDK/openjdk-jdk8u-backup#4

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 26 (12 by maintainers)

Commits related to this issue

Most upvoted comments

Seeing a possibly related error on MacOS 10.13.6 using AdoptOpenJDK jdk8u172-b11 Setting up a symlink is a workaround for the issue: ln -s libfreetype.dylib.6 libfreetype.6.dylib

Stacktrace Exception in thread "main" java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib Referenced from: /Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib Reason: image not found at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:93)

#1 cd to the jdk path lib “/Contents/Home/jre/lib” #2 then “sudo ln -s libfreetype.dylib.6 libfreetype.6.dylib” It worked for me.

#1 cd to the jdk path lib “/Contents/Home/jre/lib” #2 then “sudo ln -s libfreetype.dylib.6 libfreetype.6.dylib” It worked for me.

Thanks for this workaround. This affected creating PDFs as well (via a backend service), not just on a GUI app.

It appears to be a subtle difference between versions of Mac OS X. Hope to have this resolved next week for future builds!

The workaround is to create a symlink: libfreetype.6.dylib -> libfreetype.dylib.6

Here a basic example of what triggers the exception:

poi-example.zip

The example does run on an Oracle jdk8.

Stack trace when running the test:

runningPoiResultsInLinkError(com.example.poi.link.PoiLinkTest) Time elapsed: 0.958 sec <<< ERROR! java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib Referenced from: /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/libfontmanager.dylib Reason: image not found at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:61) at java.security.AccessController.doPrivileged(Native Method) at sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32) at sun.font.SunFontManager$1.run(SunFontManager.java:339) at java.security.AccessController.doPrivileged(Native Method) at sun.font.SunFontManager.<clinit>(SunFontManager.java:335) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at sun.font.FontManagerFactory$1.run(FontManagerFactory.java:82) at java.security.AccessController.doPrivileged(Native Method) at sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) at java.awt.Font.getFont2D(Font.java:491) at java.awt.Font.canDisplayUpTo(Font.java:2060) at java.awt.font.TextLayout.singleFont(TextLayout.java:470) at java.awt.font.TextLayout.<init>(TextLayout.java:531) at org.apache.poi.ss.util.SheetUtil.getColumnWidth(SheetUtil.java:208) at org.apache.poi.xssf.streaming.SXSSFSheet.autoSizeColumn(SXSSFSheet.java:1166) at org.apache.poi.xssf.streaming.SXSSFSheet.autoSizeColumn(SXSSFSheet.java:1148) at com.example.poi.link.PoiLinkTest.runningPoiResultsInLinkError(PoiLinkTest.java:14)

Is the root cause just that the filename has “6” and “dylib” in the wrong order? Because that’s be pretty funny, and hopefully an easy fix.

It appears to be a subtle difference between versions of Mac OS X

On non-macOS UNIX-like operating systems, the shared library suffix is “so” and it occurs before any version number (e.g. “libfreetype.so.6”). On macOS, the dynamic library suffix is “dylib” and it occurs after the optional major version number (e.g. “libfreetype.6.dylib”). All versions of macOS follow this convention. Probably there is somewhere in the build system where an assumption that the version number should appear after the suffix is incorrectly being applied when building on macOS.