[MDEV-12810] mariabackup requires libcrc.so Created: 2017-05-16  Updated: 2017-05-18  Resolved: 2017-05-18

Status: Closed
Project: MariaDB Server
Component/s: Backup
Affects Version/s: 10.1.23
Fix Version/s: 10.1.24

Type: Bug Priority: Major
Reporter: Oden Eriksson Assignee: Vladislav Vaintroub
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS7

Sprint: 10.1.24

 Description   

Hi,

I'm keeping my own backports from rawhide and essentially bump the version when needed.

This time there is a problem when building extra/mariabackup because you cannot install the built RPM packages due to missing deps.

 
 
$ rpm -qp --requires mariadb-10.1.23-0.1.el7.centos.x86_64.rpm | grep crc
 
libcrc.so()(64bit)
 
 
 
When I extract the mariabackup binary I see:
 
 
 
$ ldd mariabackup | grep crc
 
        libcrc.so => not found

I suspect some cmake voodoo magic is required to build libcrc (extra/mariabackup/crc) statically and not exporting any symbols.

Cheers.

 Comments   
Comment by Sergei Golubchik [ 2017-05-16 ]

Hi, oden. As far as I can see, extra/mariabackup is always compiled with extra/mariabackup/crc — it never looks for a system libcrc.so (if such a thing can possibly exist at all). Furthermore, libcrc.a is built statically for me, I've tried a couple of times with different build configurations. How exactly do you configure your build? With what arguments do you run cmake?

Comment by Oden Eriksson [ 2017-05-16 ]

Hi,

Please see: https://nux.se/repo/mariadb.spec

Comment by Sergei Golubchik [ 2017-05-16 ]

On the first glance, build configuration looks ok. My first suspect would be one of your ~14 patches that you apply. The second would be your ancient cmake 2.6.4.

What are these patches doing?

Comment by Vladislav Vaintroub [ 2017-05-16 ]

The problem that I see with how crc is built is that there is not STATIC in ADD_LIBRARY.
The documentation for add_library() https://cmake.org/cmake/help/v3.0/command/add_library.html states :

"If no type is given explicitly the type is STATIC or SHARED based on whether the current value of the variable BUILD_SHARED_LIBS is ON" . So it may be built as shared library, if we imagine that one of ~14 patches sets BUILD_SHARED_LIBS to ON.

Comment by Oden Eriksson [ 2017-05-17 ]

Of course 10.1.22 built fine but then suddenly mariabackup, mbstream, wsrep_sst_mariabackup and a lot of man pages was suddenly added.

You should probably also add "BuildRequires: libarchive-devel" for mariabackup, noted elsewhere in your spec file / cmake cpack thingie.

CentOS7 (RHEL7) has cmake-2.8.12.2

You can DL the Redhat Rawhide src.rpm file here an examine the patches, none sets BUILD_SHARED_LIBS to ON: ftp://ftp.acc.umu.se/mirror/fedora/linux/development/rawhide/Everything/source/tree/Packages/m/mariadb-10.1.21-3.fc26.src.rpm

Comment by Sergei Golubchik [ 2017-05-17 ]

I looked the patches through — nothing that could've affected how libcrc is built.

Comment by Oden Eriksson [ 2017-05-18 ]

Sorry guys, I just realized there's a rpm macro that indeed does this. I don't do rpm packaging all day long anymore...

 
 
[root@localhost /]# cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 
 
 
[root@localhost /]# rpm --eval %cmake
 
 
 
  CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic}" ; export CFLAGS ; 
  CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic}" ; export CXXFLAGS ; 
  FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -I/usr/lib64/gfortran/modules}" ; export FFLAGS ; 
  FCFLAGS="${FCFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -I/usr/lib64/gfortran/modules}" ; export FCFLAGS ; 
  LDFLAGS="${LDFLAGS:--Wl,-z,relro }" ; export LDFLAGS ; 
  /usr/bin/cmake \
 
        -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
 
        -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
 
        -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
 
        -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
 
        -DCMAKE_INSTALL_PREFIX:PATH=/usr \
 
        -DINCLUDE_INSTALL_DIR:PATH=/usr/include \
 
        -DLIB_INSTALL_DIR:PATH=/usr/lib64 \
 
        -DSYSCONF_INSTALL_DIR:PATH=/etc \
 
        -DSHARE_INSTALL_PREFIX:PATH=/usr/share \
 
%if "lib64" == "lib64" 
        -DLIB_SUFFIX=64 \
 
%endif 
        -DBUILD_SHARED_LIBS:BOOL=ON

So, I think this problem needs to be fixed as more distros than redhat used this rpm macro. I see that Mageia is still at 10.1.22.

Comment by Oden Eriksson [ 2017-05-18 ]

This appears to fix the problem:

 
 
diff -Naurp mariadb-10.1.23/extra/mariabackup/crc/CMakeLists.txt mariadb-10.1.23.oden/extra/mariabackup/crc/CMakeLists.txt
 
--- mariadb-10.1.23/extra/mariabackup/crc/CMakeLists.txt        2017-05-02 07:13:39.000000000 +0200
 
+++ mariadb-10.1.23.oden/extra/mariabackup/crc/CMakeLists.txt   2017-05-18 08:08:52.716737991 +0200
 
@@ -30,4 +30,4 @@ ENDIF()
 
 IF(HAVE_CLMUL_INSTRUCTION)
 
   ADD_DEFINITIONS(-DHAVE_CLMUL_INSTRUCTION)
 
 ENDIF()
 
-ADD_LIBRARY(crc crc_glue.c crc-intel-pclmul.c)
 
+ADD_LIBRARY(crc STATIC crc_glue.c crc-intel-pclmul.c)
 
 

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