Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8139653

Freetype bundled on macosx, but not correctly linked

    Details

    • Subcomponent:
    • Resolved In Build:
      b35
    • OS:
      os_x

      Backports

        Description

        When building OpenJDK on Macosx, we bundle the freetype library if specifically specified on the configure command line, but not if it's found on the system. But because of how the linking works, libfontmanager will always just look for freetype in /opt/X11/lib/libfreetype.6.so. To fix this, we need to patch libfontmanager.dylib to look in @rpath/libfreetype.dylib instead when bundling freetype.

        Note that Oracle produced openjdk macos builds do not currently bundle freetype.

          Issue Links

            Activity

            Hide
            ihse Magnus Ihse Bursie added a comment -
            It seems to me that the correct solution is to stop bundling freetype with the macosx builds.

            The logic in the configure script is highly convoluted. If I parse it correctly, in effect it says:
            1) if --with-freetype[-*] is used, the following applies:
                  if test "x$BUNDLE_FREETYPE" = x; then
                    # If not specified, default is to bundle freetype
                    BUNDLE_FREETYPE=yes
                  fi
            2) else, the following applies:
                  if test "x$BUNDLE_FREETYPE" = x; then
                    # If not specified, default is to bundle freetype only on windows
                    if test "x$OPENJDK_TARGET_OS" = xwindows; then
                      BUNDLE_FREETYPE=yes
                    else
                      BUNDLE_FREETYPE=no
                    fi
                  fi

            So this means that if freetype is autodetected on macosx, it will not be bundled by default, but if we specify a specific path, it will be bundled by default. I can't see any good reason for this behavior.
            Show
            ihse Magnus Ihse Bursie added a comment - It seems to me that the correct solution is to stop bundling freetype with the macosx builds. The logic in the configure script is highly convoluted. If I parse it correctly, in effect it says: 1) if --with-freetype[-*] is used, the following applies:       if test "x$BUNDLE_FREETYPE" = x; then         # If not specified, default is to bundle freetype         BUNDLE_FREETYPE=yes       fi 2) else, the following applies:       if test "x$BUNDLE_FREETYPE" = x; then         # If not specified, default is to bundle freetype only on windows         if test "x$OPENJDK_TARGET_OS" = xwindows; then           BUNDLE_FREETYPE=yes         else           BUNDLE_FREETYPE=no         fi       fi So this means that if freetype is autodetected on macosx, it will not be bundled by default, but if we specify a specific path, it will be bundled by default. I can't see any good reason for this behavior.
            Hide
            ihse Magnus Ihse Bursie added a comment -
            After offline discussions with [~erikj], the conclusion is that we should keep bundling freetype for mac, and we should make sure it works. We might also reconsider the logic on how and when to default to bundling.
            Show
            ihse Magnus Ihse Bursie added a comment - After offline discussions with [~erikj], the conclusion is that we should keep bundling freetype for mac, and we should make sure it works. We might also reconsider the logic on how and when to default to bundling.
            Hide
            erikj Erik Joelsson added a comment -
            I have fixed the issue using a tool called "install_name_tool". With this we can rewrite the rpath to libfreetype in libfontmanager to be a relative path in the same directory. I also changed the copy logic to stop adding .6 to the library name when bundling freetype on macosx.

            In order to actually use this logic in our internal Openjdk builds on macosx, we need to produce a build of libfreetype which we can bundle.
            Show
            erikj Erik Joelsson added a comment - I have fixed the issue using a tool called "install_name_tool". With this we can rewrite the rpath to libfreetype in libfontmanager to be a relative path in the same directory. I also changed the copy logic to stop adding .6 to the library name when bundling freetype on macosx. In order to actually use this logic in our internal Openjdk builds on macosx, we need to produce a build of libfreetype which we can bundle.
            Hide
            ihse Magnus Ihse Bursie added a comment -
            Does this mean that we have to modify the lib.dylib after creating it? :(
            Show
            ihse Magnus Ihse Bursie added a comment - Does this mean that we have to modify the lib.dylib after creating it? :(
            Hide
            erikj Erik Joelsson added a comment - - edited
            That's the only solution I've found so far. We could go at it the other way and require the libfreetype that we bundle to have the correct install_name set, but I think that is asking for trouble trying to explain this requirement to other openjdk builders. It's better if the openjdk build is able to handle any libfreetype binary.
            Show
            erikj Erik Joelsson added a comment - - edited That's the only solution I've found so far. We could go at it the other way and require the libfreetype that we bundle to have the correct install_name set, but I think that is asking for trouble trying to explain this requirement to other openjdk builders. It's better if the openjdk build is able to handle any libfreetype binary.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk/jdk/rev/9240097e2821
            User: erikj
            Date: 2017-11-30 21:33:49 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk/jdk/rev/9240097e2821 User: erikj Date: 2017-11-30 21:33:49 +0000

              People

              • Assignee:
                erikj Erik Joelsson
                Reporter:
                erikj Erik Joelsson
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: