[patch] Fix BZ 11420 -- configure uses incorrect link order when testing libpython

[patch] Fix BZ 11420 -- configure uses incorrect link order when testing libpython

[Paul Pluzhnikov via gdb-patches]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Greetings,

https://stackoverflow.com/a/49868387
https://sourceware.org/bugzilla/show_bug.cgi?id=11420

Configure uses "gcc -o conftest -g ... conftest.c -ldl -lncurses -lm -ldl
... -lpthread ... -lpython2.7" when deciding whether give libpython is
usable.

That of course is the wrong link order, and only works for shared libraries
(mostly by accident), and only on some systems.

Attached patch fixes this.

I am not sure about this part of the patch:

-  LIBS="$LIBS $new_LIBS"
+  LIBS="$new_LIBS $LIBS"

I think it's always better to prepend new libraries.

Thanks,

2018-04-17  Paul Pluzhnikov  <ppluzhnikov@google.com>

             PR gdb/11420
             * gdb/configure.ac: Prepend libpython.
             * gdb/python/python-config.py: Likewise.
             * gdb/configure: Regenerate.


-- 
Paul Pluzhnikov

[-- Attachment #2: gdb-bz11420-20180417.txt --]
[-- Type: text/plain, Size: 2385 bytes --]

diff --git a/gdb/configure.ac b/gdb/configure.ac
index 698fc7b834..e1f630cd38 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -732,7 +732,7 @@ AC_DEFUN([AC_TRY_LIBPYTHON],
   save_CPPFLAGS=$CPPFLAGS
   save_LIBS=$LIBS
   CPPFLAGS="$CPPFLAGS $new_CPPFLAGS"
-  LIBS="$LIBS $new_LIBS"
+  LIBS="$new_LIBS $LIBS"
   found_usable_python=no
   AC_LINK_IFELSE(AC_LANG_PROGRAM([[#include "Python.h"]],
                                  [[Py_Initialize ();]]),
@@ -922,19 +922,19 @@ else
   elif test "${have_python_config}" != failed; then
     if test "${have_libpython}" = no; then
       AC_TRY_LIBPYTHON(python2.7, have_libpython,
-                       ${python_includes}, "${python_libs} -lpython2.7")
+                       ${python_includes}, "-lpython2.7 ${python_libs}")
     fi
     if test "${have_libpython}" = no; then
       AC_TRY_LIBPYTHON(python2.6, have_libpython,
-                       ${python_includes}, "${python_libs} -lpython2.6")
+                       ${python_includes}, "-lpython2.6 ${python_libs}")
     fi
     if test ${have_libpython} = no; then
       AC_TRY_LIBPYTHON(python2.5, have_libpython,
-                       ${python_includes}, "${python_libs} -lpython2.5")
+                       ${python_includes}, "-lpython2.5 ${python_libs}")
     fi
     if test ${have_libpython} = no; then
       AC_TRY_LIBPYTHON(python2.4, have_libpython,
-                       ${python_includes}, "${python_libs} -lpython2.4")
+                       ${python_includes}, "-lpython2.4 ${python_libs}")
     fi
   fi
   if test "${have_libpython}" = python2.7 -o "${have_libpython}" = python27; then
diff --git a/gdb/python/python-config.py b/gdb/python/python-config.py
index c2b2969c39..0d38ed50c0 100644
--- a/gdb/python/python-config.py
+++ b/gdb/python/python-config.py
@@ -58,12 +58,11 @@ for opt in opt_flags:
         print (to_unix_path(' '.join(flags)))
 
     elif opt in ('--libs', '--ldflags'):
-        libs = []
+        libs = ['-lpython'+pyver + abiflags]
         if getvar('LIBS') is not None:
             libs.extend(getvar('LIBS').split())
         if getvar('SYSLIBS') is not None:
             libs.extend(getvar('SYSLIBS').split())
-        libs.append('-lpython'+pyver + abiflags)
         # add the prefix/lib/pythonX.Y/config dir, but only if there is no
         # shared library in prefix/lib/.
         if opt == '--ldflags':

Re: [patch] Fix BZ 11420 -- configure uses incorrect link order when testing libpython

[Paul Pluzhnikov via gdb-patches]

Ping?

> 2018-04-17  Paul Pluzhnikov  <ppluzhnikov@google.com>

>             PR gdb/11420
>              * gdb/configure.ac: Prepend libpython.
>              * gdb/python/python-config.py: Likewise.
>              * gdb/configure: Regenerate.


-- 
Paul Pluzhnikov

Re: [patch] Fix BZ 11420 -- configure uses incorrect link order when testing libpython

[Simon Marchi]

On 2018-04-17 11:52, Paul Pluzhnikov via gdb-patches wrote:
> Greetings,
> 
> https://stackoverflow.com/a/49868387
> https://sourceware.org/bugzilla/show_bug.cgi?id=11420
> 
> Configure uses "gcc -o conftest -g ... conftest.c -ldl -lncurses -lm 
> -ldl
> ... -lpthread ... -lpython2.7" when deciding whether give libpython is
> usable.
> 
> That of course is the wrong link order, and only works for shared 
> libraries
> (mostly by accident), and only on some systems.
> 
> Attached patch fixes this.

Hi Paul,

Sorry for letting this slip through the cracks.

It looks like our python-config.py is a (modified) copy of an old 
python-config from CPython.  A similar bug was reported and fixed 
upstream a while ago:

https://bugs.python.org/issue18096

and your fix in python-config.py makes our version closer to the 
upstream version, so this part LGTM.

> I am not sure about this part of the patch:
> 
> -  LIBS="$LIBS $new_LIBS"
> +  LIBS="$new_LIBS $LIBS"
> 
> I think it's always better to prepend new libraries.
> 
> Thanks,
> 
> 2018-04-17  Paul Pluzhnikov  <ppluzhnikov@google.com>
> 
>              PR gdb/11420
>              * gdb/configure.ac: Prepend libpython.
>              * gdb/python/python-config.py: Likewise.
>              * gdb/configure: Regenerate.

The configure changes seem good as well, or at worst noops.  For 
example, in this context, I am wondering if the python_libs value can be 
other than empty:

   elif test "${have_python_config}" != failed; then
     if test "${have_libpython}" = no; then
       AC_TRY_LIBPYTHON(python2.7, have_libpython,
                        ${python_includes}, "-lpython2.7 ${python_libs}")
     fi

If we are in that context, it's because have_python_config is "no".  And 
it looks like the only code path that sets have_python_config to "no" 
also sets python_libs to empty.  If you want to investigate that further 
and possibly simplify the code, you are welcome.

I've pushed your patch with these changes:

- Fix pre-existing formatting issue in the python-config.py line
- Re-generate configure (those changes were not included in the patch)
- Remove the gdb/ prefixes in the ChangeLog filenames (they should be 
relative to the ChangeLog file itself, which is in gdb/).

Thanks!

Simon