Uploaded image for project: 'Kudu'
  1. Kudu
  2. KUDU-2427

Add support for Ubuntu 18.04



    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.0
    • Fix Version/s: 1.8.0, 1.10.0, 1.11.0
    • Component/s: master, tserver
    • Labels:


      Ubuntu 18.04 (Bionic) is out, and since it's the next LTS release from Ubuntu we should support it. Unlike previous releases, this one is chock full of Kudu-breaking changes. It's getting difficult for me to keep track of them all, so I'll use this Jira to do that.

      New Java

      Bionic ships with both JDK8 and JDK10, but defaults to JDK10. I'm sure that'll lead to a number of issues with our Java bindings. Most immediately, though, is this cmake bug which prevents cmake from finding the JDK via find_package(Java). The bug fix is scheduled for 3.11.2 which has yet to be released; Bionic ships with a version of cmake 3.10 that has been patched to include this fix.

      New gcc

      Bionic ships with gcc5, gcc6, gcc7, and gcc8, but defaults to gcc7. Beyond the usual set of new warnings, this version of gcc cannot compile breakpad. This bug was filed, and it seems to have been fixed in the top of the breakpad tree, perhaps in this commit.

      New OpenSSL

      Bionic ships with libssl1.0 and 1.1, but defaults to 1.1. The transition from 1.0 to 1.1 broke all sorts of ABIs and APIs, some of which have been documented by KUDU-1889.

      Miscellaneous stuff

      I'm still working through several test failures that I can't yet attribute to any one particular thing. These are:

      1. Some tests that depend on libkudu_util.so appear to load that before loading libc, which causes the dl_iterate_phdr dlsym() call in util/debug/unwind_safeness.cc to fail at startup. Commenting that out leads to deadlocks in debug-util-test, so whatever underlying race existed in libc still exists.
      2. All of the tests in minidump-test fail, probably due to changes in breakpad.
      3. Symbolization via google::Symbolize appears to produce  "(unknown)" frames in code that has been statically linked. Perhaps the problem is not so generic, but this leads to failures in stack_watchdog-test, which expects to find the name of the test in one of the stack frames.


          Issue Links



              • Assignee:
                adar Adar Dembo
                adar Adar Dembo
              • Votes:
                0 Vote for this issue
                5 Start watching this issue


                • Created: