elenst
Lucky me , it's present in the centos07-bintar container image so I guess I just need to instrument CMAKE via DCURSES_NEED_NCURSES=1 ?

$ docker run --rm -it -u root --shm-size=64G quay.io/mariadb-foundation/bb-worker:centos7-bintar bash

[root@07d7cd96cee1 buildbot]# ls -l /lib64/libncurses.a

-rw-r--r-- 1 root root 331804 Sep  6  2017 /lib64/libncurses.a

elenst I managed to use libncurses.a
with a slight difference from old - buildbot. (tested on 10.6)

In new bb is looking for tputs / setupterm and vidaatr in tinfo instead of libncurses.a
Can this considered a problem?

New buildbot cmake output:
– Found Curses: /scripts/local/lib/libncurses.a
– Looking for tputs in /scripts/local/lib/libncurses.a
– Looking for tputs in /scripts/local/lib/libncurses.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

Old buildbot output
– Found Curses: /home/buildbot/local/lib/libncurses.a
– Looking for tputs in /home/buildbot/local/lib/libncurses.a
– Looking for tputs in /home/buildbot/local/lib/libncurses.a - found
– Looking for setupterm in /home/buildbot/local/lib/libncurses.a
– Looking for setupterm in /home/buildbot/local/lib/libncurses.a - found
– Looking for vidattr in /home/buildbot/local/lib/libncurses.a
– Looking for vidattr in /home/buildbot/local/lib/libncurses.a - found
– Looking for include files curses.h, term.h
– Looking for include files curses.h, term.h - found

Is the resulting mariadb binary linked with libncurses?

elenst
running ldd on the mariadb binary after applying the above changes
does not return libncurses as dynamically linked so I think we're good.

The tests I've done were for amd64-centos-7-bintar builder in new BB.

In new buildbot we have also the following active bintar builders. Should the same be applied to them?
-> aarch64-debian-10-bintar
-> x86-kvm-centos-6-bintar
-> x86-kvm-ubuntu-1604-bintar

centos-6-bintar and ubuntu-1604-bintar are only needed for 10.5, and we decided not to bother with it, so no need.

For aarch64-debian-10-bintar, as I understand, we don't release ARM bintars (at least I don't see them either in the Foundation downloads or in corporation), so it's not that important; although if it's easy to do, maybe you could do it just so that it's not forgotten later.

rvarzaru,

I still see dynamically linked ncurses in e.g. a build of Sep 18: https://ci.mariadb.org/50291/amd64-centos-7-bintar/

$ ldd bin/mariadb

	linux-vdso.so.1 (0x00007fffd25fc000)

	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f81326d9000)

	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f81326d4000)

	libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f8131bda000)

	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f8131ba9000)

	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8131800000)

	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8131aca000)

	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f813161f000)

	/lib64/ld-linux-x86-64.so.2 (0x00007f81326f8000)

	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8131aaa000)

Are your changes not in "production" yet?

elenst
I just pushed the change in production about ~30 minutes ago, sorry for the delay.
There's no branch yet that will push the package on CI but looking in the logs, it will be statically linked (same results I had when testing on DEV, where I could Inspect the pkg)

centos7 -> https://buildbot.mariadb.org/#/builders/577/builds/14263/steps/5/logs/stdio
debian10 -> https://buildbot.mariadb.org/#/builders/586/builds/12693/steps/5/logs/stdio

Let me know if there's anything to do or I can close this item. Thanks!

solved,
see -> https://ci.mariadb.org/50510/amd64-centos-7-bintar/
https://buildbot.mariadb.org/#/builders/577/builds/14303