During configure, checking for Python Library Path takes forever as the configure script uses find on multiple directories including I believe /usr to search for present python libraries. for i in "$python_path/lib/python$PYTHON_VERSION/config/" "$python_path/lib/python$PYTHON_VERSION/" "$python_path/lib/python/config/" "$python_path/lib/python/" "$python_path/" ; do if test -e "$i"; then python_path=`find $i -type f -name libpython$PYTHON_VERSION.* -print | sed "1q"` if test -n "$python_path" ; then python_lib="python$PYTHON_VERSION" break fi Reproducible: Always Steps to Reproduce: 1. Emerge package gnome-python-extras-2.25.3 as usual method 2. 3. Actual Results: checking for python extension module directory... ${exec_prefix}/lib64/python2.6/site-packages checking for headers required to compile python extensions... found checking for Python library path... *GAVE UP waiting after a few minutes* Expected Results: checking for python extension module directory... ${exec_prefix}/lib64/python2.6/site-packages checking for headers required to compile python extensions... found checking for Python library path... found The configure script in this ebuild app-office/planner also showing the same problems as part of the code was copied from here.
And what alternative should be used instead for locating proper path? (this is anyway an upstream issue). Thanks
I suggest using distutils.sysconfig.get_config_var(...).
I have seen this affects to more packages in the tree (like gnucash and others), wouldn't be possible to find a more general solution to, for example, drop that checking in favor of a better one when unpacking sources? I am referring to some fix on a eclass for not needing to fix every package showing this bug
Arfrever, if you have time, could you please try to provide a patch for explaining upstreams how to properly check for python paths? Thanks a lot
(In reply to comment #4) > Arfrever, if you have time, could you please try to provide a patch for > explaining upstreams how to properly check for python paths? The following commands should help you: $ python2.6 -c 'import distutils.sysconfig; print(distutils.sysconfig.get_python_inc())' /usr/include/python2.6 $ python2.6 -c 'import distutils.sysconfig; print(distutils.sysconfig.get_python_lib(standard_lib=True))' /usr/lib64/python2.6 $ python2.6 -c 'import distutils.sysconfig; print(distutils.sysconfig.get_python_lib(standard_lib=False))' /usr/lib64/python2.6/site-packages $ python2.6 -c 'import distutils.sysconfig; print(distutils.sysconfig.get_config_var("LDLIBRARY"))' libpython2.6.so $ python2.6 -c 'import distutils.sysconfig; print(distutils.sysconfig.get_config_var("INSTSONAME"))' libpython2.6.so.1.0 $ python2.6 -c 'import distutils.sysconfig; print(distutils.sysconfig.get_config_var("LIBRARY"))' libpython2.6.a
It's not only slow, but also apparently breaks with splitdebug: checking for Python include path... /usr/include/python2.6 checking for Python library path... find: `/usr/lib/python/config/': No such file or directory find: `/usr/lib/python/': No such file or directory /usr/lib64/debug/usr/lib64 checking python extra libraries...
It's just slow here with splitdebug and 3 python slots installed.
(In reply to comment #6) > It's not only slow, but also apparently breaks with splitdebug: > > checking for Python include path... /usr/include/python2.6 > checking for Python library path... find: `/usr/lib/python/config/': No such > file or directory > find: `/usr/lib/python/': No such file or directory > /usr/lib64/debug/usr/lib64 > checking python extra libraries... It does not really 'fail', or does it? Does the emerge fail ? It looks to me like it just tries to run find on a non-existent directory, but it finds what it searches for somewhere else.
Is there any workaround for this? I got the same problem when emerging scribes editor: each package egg-python, gtkspell-python, ... hangs at "Checking for Python Library Path..." for 5 minutes around.
Looks like changes would be like the following: http://git.gnome.org/browse/gnome-python-extras/commit/?id=77cca7ce35bfb4f6bc283672dc295c2bb82a3b58
(In reply to comment #10) It will cause new problems: - Python doesn't install python.pc, so AC_MSG_ERROR([Can't find python.pc]) will be run. - Only Python 2.7 and >=3.1 install python-${Python_version}.pc (e.g. python-2.7.pc, python-3.1.pc, python-3.2.pc), so using of python-$PYTHON_VERSION in pkg-config calls in acinclude.m4 would still break support for Python <=2.6.
(In reply to comment #11) > It will cause new problems: > - Python doesn't install python.pc Obvious solution: have eselect-python install python.pc.
(In reply to comment #12) It wouldn't work with functionality of setting of locally active version of Python (via EPYTHON environmental variable), so it cannot be implemented.
(In reply to comment #13) > It wouldn't work with functionality of setting of locally active version of > Python (via EPYTHON environmental variable), so it cannot be implemented. You are right. So we need to somehow make pkg-config EPYTHON-aware... Perhaps the eclass could generate a pkg-config wrapper script in a temporary directory under WORKDIR that does argument munging, transforming "python" into whatever is appropriate given the value of EPYTHON?
(In reply to comment #14) A pkg-config wrapper might be useful for other reasons, but it won't help for support for Python <=2.6.
(In reply to comment #15) > A pkg-config wrapper might be useful for other reasons, but it won't help for > support for Python <=2.6. python-2.6.pc can be easily generated using python2.6's distutils in a temporary directory that's added to PKG_CONFIG_PATH by the wrapper. Is there a good way to check for paths for python2.5 and python2.4? AFAICT, they don't have a distutils module.
(In reply to comment #16) > Is there a good way to check for paths for python2.5 and python2.4? AFAICT, > they don't have a distutils module. Never mind, they do have it.
(In reply to comment #11) > (In reply to comment #10) > > It will cause new problems: > - Python doesn't install python.pc, so AC_MSG_ERROR([Can't find python.pc]) > will > be run. Is this situation "normal"? I mean, looks like we are the only distribution having this problem... or upstream looks to think python.pc should be present on most of systems. > - Only Python 2.7 and >=3.1 install python-${Python_version}.pc > (e.g. python-2.7.pc, python-3.1.pc, python-3.2.pc), so using of > python-$PYTHON_VERSION in pkg-config calls in acinclude.m4 would still break > support for Python <=2.6. In the worst case we could still make them require python2.7 anyway :-/, not perfect... but I am still unsure about supporting all python2 versions in the tree
(In reply to comment #18) > Is this situation "normal"? Yes. > I mean, looks like we are the only distribution having this problem... > or upstream looks to think python.pc should be present on most of systems. python-$(VERSION).pc is always installed by Makefile of Python 2.7 and >=3.1, while an additional symlink might be created only when "bininstall" or "install" target is used. Ebuilds use "altinstall" target to decrease chance of collisions between slots. Other distributions might not support having multiple Python versions installed parallelly. Please convince upstream to use the following code in acinclude.m4: if pkg-config --exists python-$PYTHON_VERSION; then python_ldflags=`pkg-config --libs python-$PYTHON_VERSION` else python_ldflags="-lpython$PYTHON_VERSION" fi
Created attachment 277417 [details] pkg-config wrapper Well, until the upstream has been convinced, here is a pkg-config wrapper that uses the EPYTHON environmental variable to munge "python" arguments to "python-X.Y", and if EPYTHON doesn't have a pkg-config file, the wrapper generates one using distutils. To use it, stick it into ${WORKDIR}/tmp, and add ${WORKDIR}/tmp to the beginning of PATH.
(In reply to comment #20) Some options of pkg-config require an argument. (E.g. if test.pc defines "python" variable, then `pkg-config test --variable python` prints value of this variable.)
Created attachment 277419 [details] improved pkg-config wrapper (In reply to comment #21) > Some options of pkg-config require an argument. (E.g. if test.pc defines > "python" variable, then `pkg-config test --variable python` prints value of > this variable.) Good point. Here's an improved wrapper that replaces "python" only if "python" is not an argument to an option or a version specifier.
(In reply to comment #19) > (In reply to comment #18) > > Is this situation "normal"? > > Yes. > > > I mean, looks like we are the only distribution having this problem... > > or upstream looks to think python.pc should be present on most of systems. > > python-$(VERSION).pc is always installed by Makefile of Python 2.7 and >=3.1, > while an additional symlink might be created only when "bininstall" or > "install" target is used. Ebuilds use "altinstall" target to decrease chance of > collisions between slots. Other distributions might not support having multiple > Python versions installed parallelly. > > Please convince upstream to use the following code in acinclude.m4: > > if pkg-config --exists python-$PYTHON_VERSION; then > python_ldflags=`pkg-config --libs python-$PYTHON_VERSION` > else > python_ldflags="-lpython$PYTHON_VERSION" > fi Reported then: https://bugzilla.gnome.org/show_bug.cgi?id=652893
Created attachment 277639 [details, diff] gnucash-python-path.patch Are we going to fix stuff in the tree while we wait for the various upstreams? Here's a patch for gnucash to start with.
(In reply to comment #24) Please use distutils.sysconfig instead of pkg-config.
Created attachment 277725 [details, diff] gnucash-python-path.patch Hope this is better. Uses distutils.sysconfig instead of pkgconfig.
(In reply to comment #26) It looks better.
Created attachment 279157 [details, diff] planner-python-patch.patch After trying to pull similar changes to planner, configure failed with: checking if msgfmt accepts -c... yes checking for gmsgfmt... (cached) /usr/bin/gmsgfmt checking for xgettext... (cached) /usr/bin/xgettext ./configure: line 17669: syntax error: unexpected end of file Do you know what I am doing wrong? Thanks
Created attachment 279159 [details] planner config.log
(In reply to comment #28) Delete one 'python_path=`$PYTHON -c 'import distutils.sysconfig; \' from your patch.
+ 05 Jul 2011; Pacho Ramos <pacho@gentoo.org> planner-0.14.5.ebuild, + +files/planner-0.14.5-find-python.patch: + Find python in a faster way, bug #344231, upstream bug #654044. Thanks a lot + to Arfrever Frehtes Taifersar Arahesis and Ed Catmur for their help. +
+*gnucash-2.4.7 (29 Aug 2011) + + 29 Aug 2011; Pacho Ramos <pacho@gentoo.org> +gnucash-2.4.7.ebuild, + +files/gnucash-2.4.7-python-detection.patch: + Version bump, find python in a faster way, bug #344231, thanks a lot to + Arfrever Frehtes Taifersar Arahesis and Ed Catmur for their help. +
*** Bug 431176 has been marked as a duplicate of this bug. ***
Finally fixed this for gnome-python-extras-base and friends. Note that upstream had patched this issue in a different way which assumes python.pc exists and therefore is rather inconvenient for us to use in an ebuild (http://git.gnome.org/browse/gnome-python-extras/commit/?id=77cca7ce35bfb4f6bc283672dc295c2bb82a3b58). But gnome-python-extras development stopped years ago, so 2.25.3 is almost certainly the last release. > 13 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > gnome-python-extras-base-2.25.3.ebuild, > +files/gnome-python-extras-base-2.25.3-python-libs.patch: > Finally fix horribly slow python libs detection (bug #344231). > 13 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > egg-python-2.25.3.ebuild, +files/egg-python-2.25.3-python-libs.patch: > Finally fix horribly slow python libs detection (bug #344231). > 13 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > gdl-python-2.25.3.ebuild, +files/gdl-python-2.25.3-python-libs.patch: > Finally fix horribly slow python libs detection (bug #344231). > 13 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > gtkhtml-python-2.25.3.ebuild, +files/gtkhtml-python-2.25.3-python-libs.patch: > Finally fix horribly slow python libs detection (bug #344231). > 13 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > gtkspell-python-2.25.3.ebuild, > +files/gtkspell-python-2.25.3-python-libs.patch: > Finally fix horribly slow python libs detection (bug #344231). > 13 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > libgda-python-2.25.3.ebuild, +files/libgda-python-2.25.3-python-libs.patch: > Finally fix horribly slow python libs detection (bug #344231). > 13 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > libgksu-python-2.25.3.ebuild, +files/libgksu-python-2.25.3-python-libs.patch: > Finally fix horribly slow python libs detection (bug #344231).
