autoconf-archive-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Working around issue with AX_PYTHON_DEVEL


From: Albert Chu
Subject: Working around issue with AX_PYTHON_DEVEL
Date: Sun, 16 Oct 2016 08:16:27 -0700

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]