Fix PR gdb/16818, workaround Python's forcing of -export-dynamic

GDB's use of --dynamic-list to only export the proc-service symbols is
broken due to Python's "python-config --ldflags" saying we should link
with -export-dynamic, causing us to export _all_ extern symbols
anyway.  On Fedora 23:

 $ python-config --ldflags
 -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
 $ python3.4-config --ldflags
  -L/usr/lib64 -lpython3.4m -lpthread -ldl  -lutil -lm  -Xlinker -export-dynamic

Having GDB export all its symbols leads to issues such as PR gdb/16818
(GDB crashes when using name for target remote hostname:port), where a
GDB symbol unintentionally preempts a symbol in one of the NSS modules
glibc loads into the process.  NSS modules should not define symbols
outside the implementation namespace or the relevant standards, but,
alas, that's a longstanding and hard to fix issue.  See libc-alpha
discussion at:

  [symbol name space issues with NSS modules]
  https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html

Python should instead be either using GCC's symbol visibility feature
or -Wl,--dynamic-list as well, to only export Python API symbols, but,
it doesn't.  There are bugs open upstream for that:

  [Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic]
  http://bugs.python.org/issue10112

  [Use GCC visibility attrs in PyAPI_*]
  http://bugs.python.org/issue11410

But that's taking a long while to resolve.

I thought of working around this Python issue by making GDB build with
-fvisibility=hidden, as Jan suggests in Python issue 10112, as then
Python's "-Xlinker -export-dynamic" has no effect.  However, that
would need to be done in the whole source tree (bfd, libiberty, etc.),
and I think that would break GCC plugins, as I believe those have
access to all of GCCs symbols, by "design".  So we'd need a new
configure switch, or have the libraries in the tree detect which of
GCC or GDB is being built, but that doesn't work, because the answer
can be "both" with combined builds...

So this patch instead works around Python's bug, by simply sed'ing
away "-Xlinker -export-dynamic" from the result of python-config.py
--ldflags, making -Wl,--dynamic-list work again as it used to.  It's
ugly, but so is the bug...

Note that if -Wl,--dynamic-list doesn't work, we always link with
-rdynamic, so static Python should still work.

Tested on F23 with --python=python (Python 2.7) and
--python=python3.4.

gdb/ChangeLog:y
2016-05-03  Pedro Alves  <palves@redhat.com>

	* configure.ac (PYTHON_LIBS): Sed away "-Xlinker -export-dynamic".
	* configure: Regenerate.

1 files changed, 14 insertions, 0 deletions

diff --git a/gdb/configure b/gdb/configure
index bc6761f..7ade907 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -9413,6 +9413,14 @@ else
   CONFIG_SRCS="$CONFIG_SRCS python/python.c"
 fi
 
+# Work around Python http://bugs.python.org/issue10112.  See also
+# http://bugs.python.org/issue11410, otherwise -Wl,--dynamic-list has
+# no effect.  Note that the only test after this that uses Python is
+# the -rdynamic/-Wl,--dynamic-list test, and we do want that one to be
+# run without -export-dynamic too.
+PYTHON_LIBS=`echo $PYTHON_LIBS | sed -e 's/-Xlinker -export-dynamic//'`
+
+
 
 
  if test "${have_libpython}" != no; then
@@ -13705,6 +13713,12 @@ rm -f core conftest.err conftest.$ac_objext \
      # libpythonX.Y.a would get its symbols required for
      # pythonX.Y/lib-dynload/*.so modules hidden by -Wl,--dynamic-list.
      # Problem does not happen for the recommended libpythonX.Y.so linkage.
+
+     # Note the workaround for Python
+     # http://bugs.python.org/issue10112 earlier has removed
+     # -export-dynamic from PYTHON_LIBS.  That's exactly what we want
+     # here too, as otherwise it'd make this -Wl,--dynamic-list test
+     # always pass.
      old_CFLAGS="$CFLAGS"
      CFLAGS="$CFLAGS $PYTHON_CFLAGS"
      old_LIBS="$LIBS"