Thu 04 Apr 2013 10:09:35 AM UTC, comment #14:
I pushed the latest version of the macro in commit ca8373b5907cc64384169dc645163da82683895a. Thank you very much for your efforts, guys!
|
Wed 03 Apr 2013 04:58:15 PM UTC, comment #13:
that approach looks fine too me.
It also works on the mac.
another minor nitpick in that macro, the library variable should be named PYTHON_LIBS not PYTHON_LDFLAGS as LDFLAGS has a different placement on the commandline than LIBS, which is relevant for static linking (and shared with ld --as-needed)
Not sure if thats worth fixing though.
|
Tue 02 Apr 2013 08:53:06 PM UTC, comment #12:
Thanks for the notice, Julian. I looked into the Makefile that is shipped with Python, and how the compiler flags are generated there. The Makefile (in /usr/lib/python3.3/config-3.3m on my system) contains the following line:
BLDLIBRARY= -L. -lpython$(LDVERSION)
So, why not do the same? Attached is a script that uses the configuration variable LDVERSION (or VERSION if LDVERSION is not defined) instead of LDLIBRARY, SO and SOABI. The script becomes even simpler that way.
Julian (or someone else), could you comment on whether this work on MacOS?
(file #27748)
|
Tue 02 Apr 2013 05:03:27 PM UTC, comment #11:
this patch will probably break on macos
There the SO variable expands to .so, but the library is libpythonX.Y.dylib
also it won't work if python is built with debugging, then SO returns _d.so not .so on linux
|
Tue 26 Mar 2013 12:52:23 AM UTC, comment #10:
Okay, very cool. I've pushed your patch in 8af26ec0cbb410219dac0e3f8e9cb5901f96fb27. Thank you very much!
|
Mon 25 Mar 2013 11:28:08 PM UTC, comment #9:
No, the patch hasn't taken the other changes into account. To me, they do not seem to conflict, however. Attached please find my suggestion how to merge these two changes. It works on my system (Arch Linux), and I do not believe that the merged version compromises anything which the other patch fixed for Ubuntu.
(file #27687)
|
Mon 25 Mar 2013 11:13:13 PM UTC, comment #8:
Does the file attachment #27682 from today take the changes from 6cb46950666b6609e931a599fc1c5317dc62a84b into account?
I tried to merge your changes into the current version of the macro, but it seemed to me like the two patches conflict and I wasn't sure how to fix the merge.
|
Mon 25 Mar 2013 06:01:59 PM UTC, comment #7:
Another typo! The corrected file is attached.
(file #27682)
|
Fri 15 Mar 2013 08:49:48 PM UTC, comment #6:
Oops, I just noticed a typo. The attached file should work now. Please ignore file #27580 from comment #5 and take this one.
(file #27610)
|
Fri 08 Mar 2013 11:45:59 PM UTC, comment #5:
The NumPy distutils have a method to determine the correct ending for shared libraries. I took the relevant code snippet from there and inserted it into the AX_PYTHON_DEVEL macro. In my opinion, this qualifies now as a permanent, OS-independent solution. Peter, would you update the file in the "testing" branch with the attached file?
(file #27580)
|
Tue 26 Feb 2013 09:44:55 AM UTC, comment #4:
I am not aware of an Autoconf macro that determines the suffix used by shared libraries. I thought that Libtool might provide that information somehow, but apparently it doesn't. It seems weird that such an elementary portability issue isn't addressed by the Autotools.
|
Wed 20 Feb 2013 08:46:58 PM UTC, comment #3:
One more comment: the proposed solution is not optimal as it guesses the ending ".so" for dynamic libraries, but that might not hold on every system. There must be a way to determine the ending for dynamic libraries within Autoconf. Is there a macro or a variable that does the job and gives me ".so", ".dll" or else, depending on the platform? I'm willing to improve the existing patch but don't know how to proceed. Any help?
|
Tue 19 Feb 2013 09:24:09 AM UTC, comment #2:
Pushed in commit 5f8f5b4348a1ae6df0eedbaef24a48c94d5c1eb5. Thank you very much for the update!
|
Mon 18 Feb 2013 10:26:53 PM UTC, comment #1:
Tested-by: Ben Widawsky <ben@bwidawsk.net>
|
Mon 18 Feb 2013 10:11:29 PM UTC, original submission:
Arch Linux uses the ending ".so" for its main Python3 library (as in "libpython3.3m.so") but Python3 itself reports the desired ending for dynamic libraries as ".cpython-33m.so". This confused AX_PYTHON_DEVEL when it tried to strip the ending from libpython. The attached fix tries to strip the ending $ac_python_soext from the library file name first (as before). If that does not work, it additionally tries to strip ".so".
(This issue is independent from my recently submitted patch here:
https://savannah.gnu.org/patch/?7951
However, both patches are necessary to make the Python-related autoconf macros work on Arch Linux.)
|