Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
* Alan W. Irwin [EMAIL PROTECTED] [2007-03-12 19:10]: On 2007-03-13 00:30+0100 Samuel Thibault wrote: Since you are the authors of the file, here is a forward. What do you think about this issue? (please keep [EMAIL PROTECTED] in Cc for the record) I no longer have an interest in supporting ac_python_devel.m4 because last year I discovered CMake, and now all my projects have been converted from autotools to CMake with excellent results. Thus, from now on feel free from my perspective to make any change you feel is correct to ac_python_devel.m4. I am not using this macro neither, so I am the a situation similar to that of Alan. Feel free to do whatever you want with this m4 file. Thanks, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414556: autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS
Samuel Thibault, le Mon 12 Mar 2007 14:51:57 +0100, a écrit : When using ac_python_devel.m4, the PYTHON_LDFLAGS variable is set to -L/usr/lib/python2.4 -lpython2.4, but libpython2.4.so and libpython2.4.a are provided in /usr/lib/python2.4/config/, not /usr/lib/python2.4/ Maybe config/ should just be appended to what get_python_lib(0,1) returns? And a compilation log of python-ldap on windows confirms this: gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.5.12-i686-2.4/Modules/LDAPObject.o ... -L/usr/local/openldap-OPENLDAP_REL_ENG_2_2/lib -L/usr/local/sasl/lib -L/usr/lib/python2.4/config -Wl,-R/usr/local/openldap-OPENLDAP_REL_ENG_2_2/lib -Wl,-R/usr/local/sasl/lib -lldap_r -llber -lssl -lcrypto -lsasl2 -lpython2.4 -o build/lib.cygwin-1.5.12-i686-2.4/_ldap.dll Samuel
Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
From http://docs.python.org/dist/module-distutils.sysconfig.html : get_python_lib( [plat_specific[, standard_lib[, prefix]]]) Return the directory for either the general or platform-dependent library installation. If plat_specific is true, the platform-dependent include directory is returned; if false or omitted, the platform-independent directory is returned. If prefix is given, it is used as either the prefix instead of PREFIX, or as the exec-prefix instead of EXEC_PREFIX if plat_specific is true. If standard_lib is true, the directory for the standard library is returned rather than the directory for the installation of third-party extensions. So maybe the fix should be calling get_python_lib(1,1) instead than w/ (0,1). On my machine they return the same thing, but depending on how you packaged python it may be the case they're different. If that doesn't fix it, afaik it's a problem packaging python, or a bug in python's distutils itself. If you want to fix it as Samuel purposed, the real fix would be to try looking for a the library in both the result of get_python_lib(0,1), w/ (1,1) and then in get_python_lib(...) + /config, and picking the first match. That would be more platform independent. Let me hear about any outcome. Matteo Il giorno mar, 13/03/2007 alle 00.30 +0100, Samuel Thibault ha scritto: Hi, Since you are the authors of the file, here is a forward. What do you think about this issue? (please keep [EMAIL PROTECTED] in Cc for the record) Samuel - Forwarded message from Samuel Thibault [EMAIL PROTECTED] - From: Samuel Thibault [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS Date: Mon, 12 Mar 2007 14:51:57 +0100 Bcc: Samuel Thibault [EMAIL PROTECTED] User-Agent: Mutt/1.5.11 Package: autoconf-archive Version: 20060312-1 Severity: normal Hi, When using ac_python_devel.m4, the PYTHON_LDFLAGS variable is set to -L/usr/lib/python2.4 -lpython2.4, but libpython2.4.so and libpython2.4.a are provided in /usr/lib/python2.4/config/, not /usr/lib/python2.4/ Maybe config/ should just be appended to what get_python_lib(0,1) returns? Samuel -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
Hi, Matteo Settenvini, le Tue 13 Mar 2007 14:13:36 +0100, a écrit : From http://docs.python.org/dist/module-distutils.sysconfig.html : get_python_lib( [plat_specific[, standard_lib[, prefix]]]) Return the directory for either the general or platform-dependent library installation. By library, I guess they mean python library, i.e. where .py files are. If plat_specific is true, By plat_specific, I guess they mean architecture-compiled python library, i.e. where .pyc files are. So maybe the fix should be calling get_python_lib(1,1) instead than w/ (0,1). This is probably needed indeed (since we want a platform-dependant thing), but that will still give us only the path to the .pyc files, not to libpythonx.y.so Samuel
Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
Matteo Settenvini, le Tue 13 Mar 2007 14:13:36 +0100, a écrit : If that doesn't fix it, afaik it's a problem packaging python, or a bug in python's distutils itself. If you want to fix it as Samuel purposed, the real fix would be to try looking for a the library in both the result of get_python_lib(0,1), w/ (1,1) and then in get_python_lib(...) + /config, and picking the first match. That would be more platform independent. I've just tried to compile install a plain upstream python this way: ./configure --prefix=/usr --exec-prefix=/usr/my-arch --enable-shared (/usr/my-arch is in the ld and ld.so default search path) libpython2.4.so got installed in /usr/my-arch/lib, libpython2.4.a in /usr/my-arch/lib/python2.4/config/, get_python_lib(0,1) returns /usr/lib/python2.4 and get_python_lib(1,1) returns /usr/my-arch/lib/python2.4. To sum it up, it looks like upstream python considers that shared libpython library should go into the system's usual library path (/usr/my-arch/lib) and the static libpython library should go into get_python_lib(1,1)+/config. That would mean that for dynamically linking with libpython, there is no need for -L, and for static libraries, one needs to use -L+get_python_lib(1,1)+/config. Samuel
Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
Il giorno mar, 13/03/2007 alle 14.30 +0100, Samuel Thibault ha scritto: Hi, Matteo Settenvini, le Tue 13 Mar 2007 14:13:36 +0100, a écrit : From http://docs.python.org/dist/module-distutils.sysconfig.html : get_python_lib( [plat_specific[, standard_lib[, prefix]]]) Return the directory for either the general or platform-dependent library installation. By library, I guess they mean python library, i.e. where .py files are. Yes, you're obviously right and I was obviously wrong. Sorry. What does distutils.sysconfig.get_config_var(LDLIBRARYDIR) returns? If non-empty I guess it should contain what we want but I ain't sure (it's an empty string here). I suppose so given that get_config_var(LDLIBRARY) returns the correct soname. Samuel Cheers, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
Matteo Settenvini, le Tue 13 Mar 2007 14:54:40 +0100, a écrit : Il giorno mar, 13/03/2007 alle 14.30 +0100, Samuel Thibault ha scritto: Hi, Matteo Settenvini, le Tue 13 Mar 2007 14:13:36 +0100, a écrit : From http://docs.python.org/dist/module-distutils.sysconfig.html : get_python_lib( [plat_specific[, standard_lib[, prefix]]]) Return the directory for either the general or platform-dependent library installation. By library, I guess they mean python library, i.e. where .py files are. Yes, you're obviously right and I was obviously wrong. Sorry. What does distutils.sysconfig.get_config_var(LDLIBRARYDIR) returns? On the same fresh upstream python build, '' . get_config_var(LDLIBRARY) returns libpython2.4.so Samuel
Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
Il giorno mar, 13/03/2007 alle 14.59 +0100, Samuel Thibault ha scritto: Matteo Settenvini, le Tue 13 Mar 2007 14:54:40 +0100, a écrit : Yes, you're obviously right and I was obviously wrong. Sorry. What does distutils.sysconfig.get_config_var(LDLIBRARYDIR) returns? On the same fresh upstream python build, '' . get_config_var(LDLIBRARY) returns libpython2.4.so Samuel So I guess that part of LDFLAGS can be cut off the macro because it's wrong. Thanks for your help! Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Bug#414556: autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS
Package: autoconf-archive Version: 20060312-1 Severity: normal Hi, When using ac_python_devel.m4, the PYTHON_LDFLAGS variable is set to -L/usr/lib/python2.4 -lpython2.4, but libpython2.4.so and libpython2.4.a are provided in /usr/lib/python2.4/config/, not /usr/lib/python2.4/ Maybe config/ should just be appended to what get_python_lib(0,1) returns? Samuel -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) autoconf-archive depends on no packages. Versions of packages autoconf-archive recommends: ii autoconf 2.61-4 automatic configure script builder -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
Hi, Since you are the authors of the file, here is a forward. What do you think about this issue? (please keep [EMAIL PROTECTED] in Cc for the record) Samuel - Forwarded message from Samuel Thibault [EMAIL PROTECTED] - From: Samuel Thibault [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS Date: Mon, 12 Mar 2007 14:51:57 +0100 Bcc: Samuel Thibault [EMAIL PROTECTED] User-Agent: Mutt/1.5.11 Package: autoconf-archive Version: 20060312-1 Severity: normal Hi, When using ac_python_devel.m4, the PYTHON_LDFLAGS variable is set to -L/usr/lib/python2.4 -lpython2.4, but libpython2.4.so and libpython2.4.a are provided in /usr/lib/python2.4/config/, not /usr/lib/python2.4/ Maybe config/ should just be appended to what get_python_lib(0,1) returns? Samuel -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) autoconf-archive depends on no packages. Versions of packages autoconf-archive recommends: ii autoconf 2.61-4 automatic configure script builder -- no debconf information - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414556: [autoconf-archive: ac_python_devel.m4 sets useless -L in PYTHON_LDFLAGS]
On 2007-03-13 00:30+0100 Samuel Thibault wrote: Hi, Since you are the authors of the file, here is a forward. What do you think about this issue? (please keep [EMAIL PROTECTED] in Cc for the record) Hi Samuel, I no longer have an interest in supporting ac_python_devel.m4 because last year I discovered CMake, and now all my projects have been converted from autotools to CMake with excellent results. Thus, from now on feel free from my perspective to make any change you feel is correct to ac_python_devel.m4. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
