Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
BB V1.0
-
Sprint 2 (27.01.2025)
Description
As tests performed by cvicentiu revealed in:
https://jira.mariadb.org/browse/MDBF-883 and
https://jira.mariadb.org/browse/MDBF-866
we are facing the following issues that shall be addressed for the current release.
The first one is related to the extra dependency of mariadb client
ERROR: We have extra deps for bin/mariadb! {'libtinfo.so.6'} |
This is caused by a couple missing functions in the static library libncurses.a in both centos-7-bintar and almalinux-8-bintar.
Although libtinfo.a is present in the CMAKE_LIBRARY_PATH, CMAKE / readline.cmake cannot detect it and it actually looks for the shared tinfo library
https://buildbot.mariadb.org/#/builders/857/builds/1/steps/5/logs/stdio
From the logs:
-- Found Curses: /scripts/local/lib/libcurses.a
|
-- Looking for tputs in /scripts/local/lib/libcurses.a |
-- Looking for tputs in /scripts/local/lib/libcurses.a - not found |
-- Looking for tputs in tinfo |
-- Looking for tputs in tinfo - found |
-- Looking for setupterm in tinfo |
-- Looking for setupterm in tinfo - found |
-- Looking for vidattr in tinfo |
-- Looking for vidattr in tinfo - not found |
-- Looking for include files curses.h, term.h |
-- Looking for include files curses.h, term.h - found |
For CMAKE to succesfully find tputs, setupterm and vidattr in libncurses.a
the .src.rpm of NCURSES should be altered to remove the following configuration parameters and then compile again.
--with-terminfo-dirs=%{_sysconfdir}/terminfo:%{_datadir}/terminfo \\\
|
--with-termlib=tinfo \\\
|
--disable-wattr-macros
|
The second problem is related to the duplicate libgalera_smm.so in the final binary tarball.
This is caused by specifying CMAKE -DEXTRA_FILES flag which was set to include the library in both paths i.e.:
-DEXTRA_FILES="${WSREP_PROVIDER}=lib;${WSREP_PROVIDER}=lib/galera;" |
Attachments
Issue Links
Activity
I deployed the changes to buildbot.mariadb.org
I've rebuild one build per each builder to validate that libtinfo is no longer dinamically linked to the client.
almalinux-8-bintar
main
- Build: https://buildbot.mariadb.org/#/builders/857/builds/7
- Package: https://ci.mariadb.org/53788/amd64-almalinux-8-bintar/mariadb-11.8.0-linux-systemd-x86_64.tar.gz
mariadb-11.8.0-linux-systemd-x86_64$ ldd bin/mariadb |
linux-vdso.so.1 (0x00007e97fcab0000) |
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007e97fca8f000) |
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007e97fca8a000) |
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007e97fba00000) |
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007e97fc99d000) |
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007e97fc96f000) |
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007e97fb600000) |
/lib64/ld-linux-x86-64.so.2 (0x00007e97fcab2000) |
centos-7-bintar
11.4
- Build: https://buildbot.mariadb.org/#/builders/577/builds/17511
- Package: https://ci.mariadb.org/53823/amd64-centos-7-bintar/mariadb-11.4.5-linux-systemd-x86_64.tar.gz
mariadb-11.4.5-linux-systemd-x86_64$ ldd bin/mariadb |
linux-vdso.so.1 (0x000078be45ab5000) |
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000078be45a94000) |
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000078be45a8f000) |
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x000078be44a00000) |
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000078be459a2000) |
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000078be45974000) |
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000078be44600000) |
/lib64/ld-linux-x86-64.so.2 (0x000078be45ab7000) |
serg Tested with the validation script. The new packages have only the following errors, all of which will be fixed with the release prep script for the upcoming release. We'll look to automate this part in the future, as discussed. I with sync with elenst and dbart about which Galera should be part of bintars packaging.
INFO: Product version (major.minor) 10.6
|
INFO: Extracting archive ../some_dlds/mariadb-10.6.21-linux-systemd-x86_64.tar.gz
|
INFO: Fetching archive dependencies
|
ERROR: We have missing files from the archive! {'bin/garbd', 'lib/libgalera_smm.so'}
|
ERROR: We have missing deps for lib/plugin/auth_gssapi.so! {'libpthread.so.0'}
|
INFO: Product version (major.minor) 10.11
|
INFO: Extracting archive ../some_dlds/mariadb-10.11.11-linux-systemd-x86_64.tar.gz
|
INFO: Fetching archive dependencies
|
ERROR: We have missing files from the archive! {'bin/garbd', 'lib/libgalera_smm.so'}
|
ERROR: We have missing deps for lib/plugin/auth_gssapi.so! {'libpthread.so.0'}
|
INFO: Product version (major.minor) 11.4
|
INFO: Extracting archive ../some_dlds/mariadb-11.4.5-linux-systemd-x86_64.tar.gz
|
INFO: Fetching archive dependencies
|
ERROR: We have missing files from the archive! {'bin/garbd', 'lib/libgalera_smm.so'}
|
ERROR: We have missing deps for lib/plugin/auth_gssapi.so! {'libpthread.so.0'}
|
INFO: Product version (major.minor) 11.7
|
INFO: Extracting archive ../some_dlds/mariadb-11.7.2-linux-systemd-x86_64.tar.gz
|
INFO: Fetching archive dependencies
|
ERROR: We have missing files from the archive! {'bin/garbd'}
|
ERROR: We have missing deps for lib/plugin/auth_gssapi.so! {'libpthread.so.0'}
|
ERROR: We have extra deps for lib/libgalera_smm.so! {'libcrypto.so.1.1', 'libssl.so.1.1'}
|
ERROR: We have missing deps for lib/libgalera_smm.so! {'libssl.so.1.0.0', 'libcrypto.so.1.0.0'}
|
INFO: Product version (major.minor) 11.8
|
INFO: Extracting archive ../some_dlds/mariadb-11.8.0-linux-systemd-x86_64.tar.gz
|
INFO: Fetching archive dependencies
|
ERROR: We have extra files! {'lib/libgalera_smm.so'}
|
ERROR: We have missing deps for lib/plugin/auth_gssapi.so! {'libpthread.so.0'}
|
I with sync with Elena Stepanova and
I won't be the one defining this requirement.
cvicentiu, serg
Applied the changes in buildbot.dev.mariadb.org and I've build all the test-cases from the previous builds.
Vicentiu please help me with a review on https://github.com/MariaDB/buildbot/pull/696
The same ncurses.sh changes were applied to centos7-bintar image too. (see /changelog in the container image)
Please check the following runs/packages, if OK I can deploy to production as soon as possible.
Centos-7-bintar
10.6
10.11
11.4
Almalinux-8-bintar
11.7
11.8