[MDEV-4893] MariaDB10 "-DWITH-SSL=/path/to/external/install" not sufficient; fails to link against external libs Created: 2013-08-13  Updated: 2013-08-14  Resolved: 2013-08-14

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.4
Fix Version/s: 10.0.5

Type: Bug Priority: Minor
Reporter: pgnd Assignee: Vladislav Vaintroub
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

uname -a
Linux dev.loc 3.7.10-1.16-desktop #1 SMP PREEMPT Fri May 31 20:21:23 UTC 2013 (97c14ba) x86_64 x86_64 x86_64 GNU/Linux
gcc -v
gcc version 4.8.1 20130806 [gcc-4_8-branch revision 201525] (SUSE Linux)



 Description   

I'm building MariaDB 10, r3781, on

    uname -a
        Linux dev.loc 3.7.10-1.16-desktop #1 SMP PREEMPT Fri May 31 20:21:23 UTC 2013 (97c14ba) x86_64 x86_64 x86_64 GNU/Linux
    gcc -v
        gcc version 4.8.1 20130806 [gcc-4_8-branch revision 201525] (SUSE Linux) 

I've built/installed OpenSSL into an external path

    pkg-config --modversion openssl
        1.0.1e
    pkg-config --libs openssl
        -L/usr/local/ssl/lib64 -lssl -lcrypto  
    pkg-config --cflags openssl
        -I/usr/local/ssl/include  

Checking MariaDB/cmake ssl-related vars prior to build

    cd bld/
    cmake .. -LAH | egrep -i "crypto|ssl|rpath|suffix"
        -- suffixes <.so;.a>
        -- OPENSSL_INCLUDE_DIR = /usr/include
        -- OPENSSL_LIBRARIES = /usr/lib64/libssl.so
        -- CRYPTO_LIBRARY = /usr/lib64/libcrypto.so
        -- OPENSSL_MAJOR_VERSION = 1
        -- SSL_LIBRARIES = /usr/lib64/libssl.so;/usr/lib64/libcrypto.so;dl
        CMAKE_SKIP_INSTALL_RPATH:BOOL=NO
        CMAKE_SKIP_RPATH:BOOL=NO
        CRYPTO_LIBRARY:FILEPATH=/usr/lib64/libcrypto.so
        OPENSSL_INCLUDE_DIR:PATH=/usr/include
        OPENSSL_LIBRARIES:FILEPATH=/usr/lib64/libssl.so
        OPENSSL_ROOT_DIR:PATH=/usr
 
    cat BUILD/SETUP.sh
        ...
        # SSL library to use.--with-ssl will select our bundled yaSSL
        # implementation of SSL. To use OpenSSL you will need to specify
        # the location of OpenSSL headers and libs on your system.
        # Ex --with-ssl=/usr
        SSL_LIBRARY=--with-ssl
        ...

talking with serg @irc, spec'ing

    -DWITH_SSL=/usr/local/ssl

should be sufficient for a link of external SSL libs.

However, with just

    cmake .. \
      ...
     -DINSTALL_LAYOUT=STANDALONE \
     -DCMAKE_SKIP_BUILD_RPATH=0 \
     -DCMAKE_BUILD_WITH_INSTALL_RPATH=1 \
     -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=1 \
     -DWITH_SSL=/usr/local/ssl \
      ...
    make

That's NOT the case – MariaDB bins are STILL un-linked against external SSL libx, using default system-installed SSL instead,

    sql/mysqld -V
        sql/mysqld  Ver 10.0.3-MariaDB-log for Linux on x86_64 (Source distribution)
    ldd sql/mysqld | egrep -i "ssl|crypto"
        (empty)
    cmake .. -LAH | egrep -i "crypto|ssl|rpath|suffix"
        -- suffixes <.a;.so>
        -- OPENSSL_INCLUDE_DIR = /usr/local/ssl/include
        -- OPENSSL_LIBRARIES = /usr/local/ssl/lib64/libssl.a
        -- CRYPTO_LIBRARY = /usr/local/ssl/lib64/libcrypto.a
        -- OPENSSL_MAJOR_VERSION = 1
        -- SSL_LIBRARIES = /usr/local/ssl/lib64/libssl.a;/usr/local/ssl/lib64/libcrypto.a;dl
        CMAKE_SKIP_INSTALL_RPATH:BOOL=NO
        CMAKE_SKIP_RPATH:BOOL=NO
        CRYPTO_LIBRARY:FILEPATH=/usr/local/ssl/lib64/libcrypto.a
        OPENSSL_INCLUDE_DIR:PATH=/usr/local/ssl/include
        OPENSSL_LIBRARIES:FILEPATH=/usr/local/ssl/lib64/libssl.a
        OPENSSL_ROOT_DIR:PATH=/usr/local/ssl
        // path to custom SSL installation
        WITH_SSL_PATH:PATH=/usr/local/ssl

OTOH, adding ADDITIONAL flags,

    cmake .. \
      ...
     -DINSTALL_LAYOUT=STANDALONE \
     -DCMAKE_SKIP_BUILD_RPATH=0 \
     -DCMAKE_BUILD_WITH_INSTALL_RPATH=1 \
     -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=1 \
     -DWITH_SSL=/usr/local/ssl \
      -DOPENSSL_LIBRARIES=/usr/local/ssl/lib64/libssl.so \
      -DOPENSSL_INCLUDE_DIR=/usr/local/ssl/include \
      -DOPENSSL_ROOT_DIR=/usr/local/ssl \
      -DCRYPTO_LIBRARY=/usr/local/ssl/lib64/libcrypto.so \
      ...
    make

builds/links as intended against external SSL

    ldd sql/mysqld | egrep -i "ssl|crypto"
        libssl.so.1.0.0 => /usr/local/ssl/lib64/libssl.so.1.0.0 (0x00007f9e48dfb000)
        libcrypto.so.1.0.0 => /usr/local/ssl/lib64/libcrypto.so.1.0.0 (0x00007f9e48a0f000)
 
    cmake .. -LAH | egrep -i "crypto|ssl|rpath|suffix"
        -- suffixes <.a;.so>
        -- OPENSSL_INCLUDE_DIR = /usr/local/ssl/include
        -- OPENSSL_LIBRARIES = /usr/local/ssl/lib64/libssl.so
        -- CRYPTO_LIBRARY = /usr/local/ssl/lib64/libcrypto.so
        -- OPENSSL_MAJOR_VERSION = 1
        -- SSL_LIBRARIES = /usr/local/ssl/lib64/libssl.so;/usr/local/ssl/lib64/libcrypto.so;dl
        CMAKE_SKIP_INSTALL_RPATH:BOOL=NO
        CMAKE_SKIP_RPATH:BOOL=NO
        CRYPTO_LIBRARY:FILEPATH=/usr/local/ssl/lib64/libcrypto.so
        OPENSSL_INCLUDE_DIR:PATH=/usr/local/ssl/include
        OPENSSL_LIBRARIES:FILEPATH=/usr/local/ssl/lib64/libssl.so
        OPENSSL_ROOT_DIR:PATH=/usr/local/ssl
        // path to custom SSL installation
        WITH_SSL_PATH:PATH=/usr/local/ssl

For a 'simple' external SSL install, in a single DIR (e.g., /usr/local/ssl), a

     -DWITH_SSL=/usr/local/ssl

config spec should be sufficient, with rpath'ing properly configured.

For more complex installs, e.g., in /usr/local, the additional flags should be available, and consistently named.



 Comments   
Comment by Sergei Golubchik [ 2013-08-14 ]

I'm not quite sure how to fix this. Simple -DWITH_SSL=/path doesn't reconfigure the existing build because it uses cached values for OPENSSL_INCLUDE_DIR, etc.

If I manually remove all SSL-related variables from the CMakeCache.txt then -DWITH_SSL=/path works.

But if ssl.cmake will unset them, then user-specified values (from the command line) for OPENSSL_INCLUDE_DIR won't work.

Comment by Vladislav Vaintroub [ 2013-08-14 ]

It is the case, when change of one cached cmake variable (WITH_SSL) should results in changes to many cached variables (OPENSSL_XXX)
In such cases it is best to build from scratch, or manually remove affected variables . doing it programmatically is can of worms.

Comment by Vladislav Vaintroub [ 2013-08-14 ]

Closing as "won't fix", since I do nto have a good idea on how to fix, and issue is minor

Comment by pgnd [ 2013-08-14 ]

???

That's one way to reduce the bug queue, I suppose.

Comment by Vladislav Vaintroub [ 2013-08-14 ]

I tried to explain why I think it is good way to close the bug. I do not mind a discussion, but you should have a better argument than ???

Generated at Thu Feb 08 07:00:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.