Linux Kokoro: link libffi.a and use centos:7
Build libffi and link it statically to the _ctypes.*.so extension
module because different glibc/x86-64 systems have different versions
of libffi.so.* (e.g. from libffi.so.6 to libffi.so.8).
Build Linux python3 in a centos:7 docker container and be more explicit
about the dynamic dependencies. CentOS 7 uses glibc 2.17, the oldest
glibc we support.
This CL changes the DT_NEEDED of the _curses module from
libncurses.so.5 to libncursesw.so.5 (the "wide"/unicode variant of
libncurses). Python generally prefers libncursesw for Unicode support
(but see Python issues #7384 and #9408 -- combining libncurses and
libncursesw in one process might break). Ubuntu 16.04 has separate
libncurses-dev and libncursesw-dev packages, and the current Kokoro
build servers only have libncurses-dev installed. CentOS, OTOH,
combines both into ncurses-devel. The change is probably OK, but in
theory, it could affect someone loading the curses module in Linux
LLDB's Python3.
Similarly, DT_NEEDED for libpanel.so.5 becomes libpanelw.so.5.
The DT_NEEDED for libbz2.so.1.0 becomes libbz2.so.1. Debian has
symlinks for both libbz2.so.1 and libbz2.so.1.0, but CentOS only has
the libbz2.so.1 symlink. This change makes the _bz2 module loadable on
both CentOS and Debian, whereas previously CentOS could not load it.
These dependencies are removed:
* libssl.so.1 --> no _ssl module
* libreadline.so.6 --> no readline module / no line editing in REPL
- New Linux systems typically didn't have this particular soname
anyway. We probably want to use libedit instead.
* libgdbm_compat.so.3 --> no _dbm module. GNU dbm isn't relevant to
the NDK, and in any case, we would have to choose between
libgdbm_compat.so.3 and libgdbm_compat.so.4.
* libgdbm.so.3 --> no _gdbm module, same as above
Bug: http://b/196424004
Test: kokoro presubmit, manually inspect DT_NEEDED entries
Change-Id: Ifbf5eb08382846fe69d2433a398f6df9c7ebd096
3 files changed
