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
- openjdk8, openjdk11: Add new port for OpenJDK 8 and migrate OpenJDK 11 to AdoptOpenJDK — committed to macports/macports-ports by breun 6 years ago
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.
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)
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.