Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-34562

tarballs link dynamically with ncurses5 - don't work on RHEL8+9

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 10.6.18
    • N/A
    • Packaging
    • None

    Description

      The Community Server binary tarball packages service multiple operating systems. The mariadb client binary is dynamically compiled against ncurses 5, RHEL8 and RHEL9 have ncurses 6 installed by default. When the client binary is executed users get the following error:

      mysql: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory
      

      The solution to this issue is to install the package ncurses-compat-libs which is available for RHEL8 and RHEL9 in the EPEL repository and provides the ncurses.so.5 library:
      https://access.redhat.com/solutions/6907421

      We should update the README.md or INSTALL-BINARY files to include this information for customers running RHEL8 or RHEL9.

      Attachments

        Issue Links

          Activity

            or rather tarballs shouldn't link with ncurses dynamically

            serg Sergei Golubchik added a comment - or rather tarballs shouldn't link with ncurses dynamically
            • 10.6 bintars are build on centos74 builder
            • centos74-amd64-build image has static curses libraries in ~/local
            • but cmake chooses dynamic curses from /usr/lib64 — this is wrong
            serg Sergei Golubchik added a comment - 10.6 bintars are build on centos74 builder centos74-amd64-build image has static curses libraries in ~/local but cmake chooses dynamic curses from /usr/lib64 — this is wrong
            wlad Vladislav Vaintroub added a comment - - edited

            Ali.maria, serg why is that "the solution"? Don't we have a replacement for ncurses, libedit or whatever it is called, bundled with the best license possible.
            I'm not sure what is required from me here.

            Why would cmake prefer static libraries in obscure places to dynamic ones in usual places?

            wlad Vladislav Vaintroub added a comment - - edited Ali.maria , serg why is that "the solution"? Don't we have a replacement for ncurses, libedit or whatever it is called, bundled with the best license possible. I'm not sure what is required from me here. Why would cmake prefer static libraries in obscure places to dynamic ones in usual places?

            we intentionally installed libncurses.a in ~/local on centos7-amd64-builder. And supposedly it was used before. Then I presume as some point cmake started to prefer dynamic system-wide linbcurses.

            you could try to figure out why cmake does that and what needs to be changed (in cmake files or in the VM) so that it would start using static libraries again

            serg Sergei Golubchik added a comment - we intentionally installed libncurses.a in ~/local on centos7-amd64-builder. And supposedly it was used before. Then I presume as some point cmake started to prefer dynamic system-wide linbcurses. you could try to figure out why cmake does that and what needs to be changed (in cmake files or in the VM) so that it would start using static libraries again

            People

              serg Sergei Golubchik
              Ali.maria Alasdair Haswell
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.