autoconf-archive-maintainers | |
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Working around issue with AX_PYTHON_DEVEL,
Albert Chu <=