Working around issue with AX_PYTHON_DEVEL

Albert Chu <[email protected]> Sun, 16 Oct 2016 08:16:27 -0700
Newsgroups gmane.comp.sysutils.autoconf.archive-maintainers
Message-ID <CAN807gbwzy3MA5sgri55Dv-YGeQwHeXjSZpC_W1XyFx5Ob_4=A@mail.gmail.com>
Hi,

I thought I'd mention something we had to work around with AX_PYTHON_DEVEL
to see if it needs consideration for a workaround/fix upstream.  We
downloaded ax_python_devel.m4 one commit behind the current master when we
hit this, but I think the issue still remains.

We have Python installed into a standard location from a distro.  So when
using AX_PYTHON_DEVEL, PYTHON_LDFLAGS gets set to "-L/usr/lib64
-lpython2.7".

In the project when we use PYTHON_LDFLAGS, a problem appears to occur b/c
"-L/usr/lib64" in PYTHON_LDFLAGS puts /usr/lib64 earlier in the linker
search than it normally would.  Normally it's later as part of the default
linker search.  So a library we have internal to the project isn't pulled
in correctly.

My workaround was to strip out the -L/usr/lib64 if -lpython2.7 was already
linkable via the default linker (or whatever LDFLAGS was set by the user at
configure time). The workaround was basically:

+      AC_CHECK_LIB([$ac_python_library], [PyArg_ParseTuple],
+                   [ac_python_in_ld_path=true])
+      if test "$ac_python_in_ld_path" = "true"; then
+        AC_MSG_NOTICE([Removing -L$ac_python_libdir from PYTHON_LDFLAGS])
+        PYTHON_LDFLAGS="-l$ac_python_library"
+      fi

The above wouldn't work for the general case (there are checks outside of
this), but I hope what I'm doing makes sense.

So wondering if -L<path> should be checked for necessity before adding it
to PYTHON_LDFLAGS?  I can attempt a patch and send it in if desired.

Thanks,

Al