Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update build scripts with location of libfreetype.6.dylib #202

Closed
smlambert opened this issue Jan 5, 2018 · 22 comments
Closed

Update build scripts with location of libfreetype.6.dylib #202

smlambert opened this issue Jan 5, 2018 · 22 comments
Assignees
Labels
bug Issues that are problems in the code as reported by the community help wanted Issues that need an extra hand helping out with them macos Issues that affect or relate to the MAC OS
Milestone

Comments

@smlambert
Copy link
Contributor

smlambert commented Jan 5, 2018

There are MANY test failures due to missing the library libfreetype.6.dylib, as described here:
adoptium/aqa-tests#136 (comment)

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.

@karianna karianna added the bug Issues that are problems in the code as reported by the community label Jan 5, 2018
@karianna karianna added this to the 1.0.0 milestone Jan 5, 2018
@karianna karianna added the help wanted Issues that need an extra hand helping out with them label Jan 5, 2018
@sxa sxa added the macos Issues that affect or relate to the MAC OS label Jan 23, 2018
@mbvreddy
Copy link

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

to

-install_name @rpath/libfreetype.6.dylib

@mbvreddy
Copy link

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
Copy link

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

@neomatrix369
Copy link
Contributor

neomatrix369 commented Feb 1, 2018

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

@neomatrix369
Copy link
Contributor

neomatrix369 commented Feb 1, 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 added a commit to neomatrix369/openjdk-build that referenced this issue Feb 1, 2018
… path embedded into the binary, and release it from the runpath dependency - as per suggestion from @mbvreddy, do it only for MacOSX builds (hence check for "darwin")

Potentially fixes issue adoptium#202
@mbvreddy
Copy link

mbvreddy commented Feb 2, 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
Copy link

mbvreddy commented Feb 2, 2018

There is another issue to take care as mentioned in #202 (comment)

@mbvreddy
Copy link

mbvreddy commented Feb 2, 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.

@neomatrix369
Copy link
Contributor

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

@smlambert
Copy link
Contributor Author

Closing as now listed in summary issue #346

@rubin55
Copy link

rubin55 commented Sep 24, 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

@karianna
Copy link
Contributor

karianna commented Sep 24, 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

@rubin55
Copy link

rubin55 commented Sep 25, 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

@karianna
Copy link
Contributor

OK thank you.

@karianna karianna reopened this Sep 25, 2018
@ksilz
Copy link

ksilz commented Nov 30, 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

@gdams
Copy link
Member

gdams commented Jan 11, 2019

Coretto had the same issue as us: corretto/corretto-8#6

@eed3si9n
Copy link

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.

@karianna
Copy link
Contributor

@eed3si9n
Copy link

@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?

@karianna
Copy link
Contributor

@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.

@ksilz
Copy link

ksilz commented Jan 21, 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

@johnoliver
Copy link
Contributor

I believe the difference in size was introduced during signing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues that are problems in the code as reported by the community help wanted Issues that need an extra hand helping out with them macos Issues that affect or relate to the MAC OS
Projects
None yet
Development

No branches or pull requests

10 participants