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

WITH_SSL works for "make" but ignored after "make install"

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.11.6, 10.4.33, 10.5.24, 10.6.17, 11.4.1
    • 11.5.1
    • Compiling
    • None
    • Ubuntu 22.04

    Description

      I use this with cmake: -DWITH_SSL=/home/mdcallag/d/openssl-111

      And it is respected during the build. If I check binaries in the build directory they are linked against it. But after "make install" when I check with ldd on the installed binaries, they reference a different path to SSL.

      In the build directory I see:

      ldd ./extra/mariabackup/mariadb-backup | grep ssl
      		 
              libssl.so.1.1 => /home/mdcallag/d/openssl-111/lib/libssl.so.1.1 (0x00007f4d68653000)
      		 
              libcrypto.so.1.1 => /home/mdcallag/d/openssl-111/lib/libcrypto.so.1.1 (0x00007f4d68364000)

      But after "make install" in the install directory I see:

      ldd ma110401_rel/bin/mariadb-backup  | grep ssl
      		 
              libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f8680acc000)

      My cmake command line is

      BF=" -g1 "
      		 
      CF=" $BF "
      		 
      CXXF=" $BF "
      		 
       
      		 
      #-DWITH_BOOST=$PWD/../boost \
      		 
      #-DCMAKE_CXX_FLAGS="$CXXF" -DCMAKE_C_FLAGS="$CF" \
      		 
      #-DWITH_NUMA=ON -DWITH_ROUTER=OFF -DWITH_MYSQLX=OFF \
      		 
      #-DWITH_SSL=system \
      		 
      #-DWITH_ZLIB=bundled \
      		 
      #-DENABLED_LOCAL_INFILE=1 \
      		 
       
      		 
      cmake .. \
      		 
      -DCMAKE_BUILD_TYPE=Release \
      		 
      -DMYSQL_MAINTAINER_MODE=OFF \
      		 
      -DCMAKE_INSTALL_PREFIX=$1 \
      		 
      -DWITH_EMBEDDED_SERVER=OFF \
      		 
      -DWITH_UNIT_TESTS=OFF \
      		 
      -DCONC_WITH_UNITTEST=OFF \
      		 
      -DCONC_WITH_SSL=OFF \
      		 
      -DWITH_SSL=/home/mdcallag/d/openssl-111 \
      		 
      -DPLUGIN_ARCHIVE=NO \
      		 
      -DPLUGIN_TOKUDB=NO \
      		 
      -DPLUGIN_MROONGA=NO \
      		 
      -DPLUGIN_OQGRAPH=NO \
      		 
      -DPLUGIN_ROCKSDB=NO \
      		 
      -DPLUGIN_CONNECT=NO \
      		 
      -DPLUGIN_SPIDER=NO

      In output from cmake I see:

      -- The following RECOMMENDED packages have been found:
      		 
       
      		 
       * OpenSSL

      And 

      -- Found OpenSSL: /home/mdcallag/d/openssl-111/lib/libcrypto.so (found version "1.1.1w")
      		 
      -- OPENSSL_INCLUDE_DIR = /home/mdcallag/d/openssl-111/include
      		 
      -- OPENSSL_SSL_LIBRARY = /home/mdcallag/d/openssl-111/lib/libssl.so
      		 
      -- OPENSSL_CRYPTO_LIBRARY = /home/mdcallag/d/openssl-111/lib/libcrypto.so
      		 
      -- OPENSSL_VERSION = 1.1.1w
      		 
      -- SSL_LIBRARIES = /home/mdcallag/d/openssl-111/lib/libssl.so;/home/mdcallag/d/openssl-111/lib/libcrypto.so;dl
      		 
      -- TLS library/version: OpenSSL 1.1.1w
      		 
      -- SYSTEM_LIBS /usr/lib/x86_64-linux-gnu/libz.so;dl;m;dl;m;/home/mdcallag/d/openssl-111/lib/libssl.so;/home/mdcallag/d/openssl-111/lib/libcrypto.so
      		 
      -- SYSTEM_LIBS: /usr/lib/x86_64-linux-gnu/libz.so;dl;m;dl;m;/home/mdcallag/d/openssl-111/lib/libssl.so;/home/mdcallag/d/openssl-111/lib/libcrypto.so;/usr/lib/x86_64-linux-gnu/libz.so
      		 
      -- SSL support: OPENSSL Libs: /home/mdcallag/d/openssl-111/lib/libssl.so;/home/mdcallag/d/openssl-111/lib/libcrypto.so

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          View 4 older comments
          wlad Vladislav Vaintroub added a comment - - edited

          I think we should remove WITH_SSL=path (because it duplicates official functionality of FindOpenSSL.cmake), like we removed WITH_DEBUG long ago.

          If MySQL thinks it is a good thing to keep this option that I introduced in 2009 (to be compatible with autotools, no other reason,and because I did not know CMake back then), I can't stop them from doing it

          We can make a better error message, and just have WITH_SSL=system|bundled.
          BTW, maybe you can live with "bundled", which is wolfssl, or is there any special reason why you're compiling with custom static OpenSSL libraries?

          wlad Vladislav Vaintroub added a comment - - edited I think we should remove WITH_SSL=path (because it duplicates official functionality of FindOpenSSL.cmake), like we removed WITH_DEBUG long ago. If MySQL thinks it is a good thing to keep this option that I introduced in 2009 (to be compatible with autotools, no other reason,and because I did not know CMake back then), I can't stop them from doing it We can make a better error message, and just have WITH_SSL=system|bundled. BTW, maybe you can live with "bundled", which is wolfssl, or is there any special reason why you're compiling with custom static OpenSSL libraries?
          mdcallag Mark Callaghan added a comment -

          Only checked this on MariaDB 10.1.48, but I get compiler errors from Mroonga with -DWITHOUT_DYNAMIC_PLUGINS=1. The fix is to add -DPLUGIN_MROONGA=NO so I don't think that WITHOUT_DYNAMIC_PLUGINS=1 does what I want it to do.

          And from cmake . -LH I see that Mroonga is dynamic
          PLUGIN_MROONGA:STRING=DYNAMIC

          mdcallag Mark Callaghan added a comment - Only checked this on MariaDB 10.1.48, but I get compiler errors from Mroonga with -DWITHOUT_DYNAMIC_PLUGINS=1. The fix is to add -DPLUGIN_MROONGA=NO so I don't think that WITHOUT_DYNAMIC_PLUGINS=1 does what I want it to do. And from cmake . -LH I see that Mroonga is dynamic PLUGIN_MROONGA:STRING=DYNAMIC
          wlad Vladislav Vaintroub added a comment -

          Yes, you're right mroonga is special . It is the only plugin that does not use MYSQL_ADD_PLUGIN, but feels the need to reinvent it in their CMakeLists.txt

          wlad Vladislav Vaintroub added a comment - Yes, you're right mroonga is special . It is the only plugin that does not use MYSQL_ADD_PLUGIN, but feels the need to reinvent it in their CMakeLists.txt
          serg Sergei Golubchik added a comment -

          wlad, I suspect there may be many custom scripts using -DWITH_SSL=. It shouldn't be difficult to set OPENSSL_ROOT_DIR and OPENSSL_USE_STATIC_LIBS if WITH_SSL is set to a path, should it?

          Unless, of course, it was totally broken for the last 15 (?) years, in which case we can assume that nobody uses it.

          serg Sergei Golubchik added a comment - wlad , I suspect there may be many custom scripts using -DWITH_SSL= . It shouldn't be difficult to set OPENSSL_ROOT_DIR and OPENSSL_USE_STATIC_LIBS if WITH_SSL is set to a path, should it? Unless, of course, it was totally broken for the last 15 (?) years, in which case we can assume that nobody uses it.
          wlad Vladislav Vaintroub added a comment - - edited

          I do not think there are many custom scripts. In the years past, I have seen this bug report, and something with openssl fips, 2 bug reports, which amounts in a bug report every 7 years. Breaking the workflow of estimated 5-6 people worldwide, who use -WITH_SSL=path, should be no concern, especially if the error message is clear and the fix is trivial.

          Going forward, I would not like our cmake to be "helpful" , and obstruct/hide all standard option from the user.

          I made an experiment, tried pretending to be CMake newbie, so I asked ChatGPT, how to use custom version of OpenSSL, and it knows about OPENSSL_ROOT_DIR. And when I asked "what if I want to link statically", it knew the correct answer as well.

          Besides, changing the behavior to be compatible with MySQL's CMake makes, wrt static linking, as proposed, would make it incompatible with our traditional compilation anyway. That static libraries are suddenly preferred now, and were not in the past, is Oracle MySQL's undocumented behavior, that by accident seemed to do the right thing for bug reporter.

          Lastly, this OPENSSL=path already was problematic for us in the past, see MDEV-27540

          wlad Vladislav Vaintroub added a comment - - edited I do not think there are many custom scripts. In the years past, I have seen this bug report, and something with openssl fips, 2 bug reports, which amounts in a bug report every 7 years. Breaking the workflow of estimated 5-6 people worldwide, who use -WITH_SSL=path, should be no concern, especially if the error message is clear and the fix is trivial. Going forward, I would not like our cmake to be "helpful" , and obstruct/hide all standard option from the user. I made an experiment, tried pretending to be CMake newbie, so I asked ChatGPT, how to use custom version of OpenSSL, and it knows about OPENSSL_ROOT_DIR. And when I asked "what if I want to link statically", it knew the correct answer as well. Besides, changing the behavior to be compatible with MySQL's CMake makes, wrt static linking, as proposed, would make it incompatible with our traditional compilation anyway. That static libraries are suddenly preferred now, and were not in the past, is Oracle MySQL's undocumented behavior, that by accident seemed to do the right thing for bug reporter. Lastly, this OPENSSL=path already was problematic for us in the past, see MDEV-27540

          People

            wlad Vladislav Vaintroub
            mdcallag Mark Callaghan
            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.