| Summary: | pygtk and pygobject cannot find Python.h during build | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chris <chris.kcat> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | python |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | pygtk config.log | ||
|
Description
Chris
2011-03-14 12:15:31 UTC
please attach full config.log as instricted by portage. Created attachment 265817 [details]
pygtk config.log
That config.log is from old pygtk-2.17 instead of 2.22. Do you have your system fully updated? As of a couple days ago, I updated everything I could. If I try to update to pygtk-2.22.0-r1, it says it requires >=dev-python/pygobject-2.21.3:2 (current version is 2.20.0). The only pygobject versions available for that are 2.21.5, 2.26.0, and 2.26.0-r1, and all exhibit the same problem and won't build. Apart of your aggressive CFLAGS and CXXFLAGS I don't know what could be causing this problem to you :-( (maybe python team will know where could it be) Do you still suffer this problem with python-2.7 after running python-updater? (In reply to comment #6) > Do you still suffer this problem with python-2.7 after running python-updater? Yup. Unmasked and installed python-2.7.1-r1, ran python-updater and let it finish, ran 'eselect python set python2.7', then tried to emerge pygobject and it failed in the same way. Looks like nobody can reproduce, I am not sure if your aggressive CFLAGS and LDFLAGS could cause problems like this :-/, maybe you should use safer values for them and "emerge -e world" Try rebuilding your python installations with safer *FLAGS Still fails. Emptied CFLAGS, rebuilt python-2.6.6-r2 and 3.1.3-r1, then tried to build pygobject again, and it failed during configure in the same way. It seems pygobject/pygtk's configure checks are only looking for Python.h in the standard include paths, not in /usr/include/python2.6 or /usr/include/python3.1, where they are. The problem is that you are the only one suffering this, then, we need to know what is wrong on your setup. You should only have python-2.7 now after updating and running python-updater (not python-2.6), then, try to have only python3.1 and python2.7 My working setup has the following files: $ ls -l $(locate Python.h) -rw-r--r-- 1 root root 4329 mar 24 22:22 /usr/include/python2.7/Python.h -rw-r--r-- 1 root root 3502 mar 3 14:52 /usr/include/python3.1/Python.h Installed python:2.7, ran python-updater, selected python 2.7, uninstalled python:2.6. # ls -l $(find /usr/include -name Python.h) -rw-r--r-- 1 root root 4329 Apr 20 09:30 /usr/include/python2.7/Python.h -rw-r--r-- 1 root root 3502 Apr 20 22:55 /usr/include/python3.1/Python.h pygobject still fails during configure. I found the issue, but I don't know what the real cause is. It seems the /usr/bin/python-config script (generated by eselect python set ...) is broken and always errors. So I guess the configure script runs `python-config --cflags` or something to get compiler switches, which errors and returns an empty string. Since the proper cflags are never added, the -I switch is never specified to point to the python header directory, causing the failure.
This is the file as generated by eselect:
#!/usr/bin/env bash
# Gentoo python-config wrapper script
[[ "${EPYTHON}" =~ (/|^python$) ]] && EPYTHON="python2.7"
python_config="${EPYTHON/python/python-config-}"
"${0%/*}/${python_config:-python-config-2.7}" "$@"
I have to modify the line like this to make it work:
[[ "${EPYTHON}" =~ \(/\|^python$\) ]] && EPYTHON="python2.7"
With that change, pygobject and pygtk will build. However, this doesn't seem like a proper fix if eselect python is just going to generate a broken wrapper script again next time...
(In reply to comment #14) What is printed by the following commands: [[ "python" =~ (/|^python$) ]]; echo $? [[ "python2.7" =~ (/|^python$) ]]; echo $? [[ "python" =~ \(/\|^python$\) ]]; echo $? [[ "python2.7" =~ \(/\|^python$\) ]]; echo $? # [[ "python" =~ (/|^python$) ]]; echo $?
0
# [[ "python2.7" =~ (/|^python$) ]]; echo $?
1
# [[ "python" =~ \(/\|^python$\) ]]; echo $?
1
# [[ "python2.7" =~ \(/\|^python$\) ]]; echo $?
1
When I run python-config (unmodified), however, I get:
# python-config
/usr/bin/python-config: line 4: unexpected argument `(' to conditional binary operator
/usr/bin/python-config: line 4: syntax error near `(/'
/usr/bin/python-config: line 4: `[[ "${EPYTHON}" =~ (/|^python$) ]] && EPYTHON="python2.7"'
You probably have an old bash in PATH. Hmm... app-shells/bash: 4.1_p9 # bash --version GNU bash, version 3.1.16(1)-release (i686-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. # equery b `which bash` [ Searching for file(s) /usr/bin/bash in *... ] # Is it supposed to be in /usr/bin/bash? /var/db/pkg/app-shells/bash-4.1_p9/CONTENTS lists /bin/bash, but I don't want to just delete /usr/bin/bash without being sure it doesn't belong somewhere. bash belongs to /bin, you can check if the files in /usr/bin belong to another package by running qfile: # qfile /bin/bash app-shells/bash (/bin/bash) If the file doesn't belong to a package it probably is an error to have it here and you should clean it up. If you have other "strange" bugs like this, I suggest you start checking your system has no left-over files like that. I'll leave this bug open to let Arfrever decide if he wants to support old bash. It seems at least eselect expects /usr/bin/bash for its interpreter, however neither qfile or equery b show /usr/bin/bash as belonging to anything. Is it supposed to be somehow generated? In my case I only have: $ whereis bash bash: /bin/bash /etc/bash /usr/share/man/man1/bash.1.bz2 $ equery b /bin/bash * Searching for /bin/bash ... app-shells/bash-4.1_p9 (/bin/bash) Then, I would remove (or move to your home if you want to be safer) that extra "bash" that you have in other places than /bin You probably manually (without using package manager) built and installed another copy of bash long time ago. We support only versions >=3.2 present in the main tree. Thanks, all of you. I cleaned out /usr/bin/bash, rebuilt some packages that had come to rely on it as its interpreter (including eselect and glibc), and things seem to be working now. :) As an aside, is there some way to look for files in /usr/bin or /usr/lib and such (not /usr/local) that don't belong to a package, to help me avoid problems like this again? Probably running "qfile -o ..." or similar :-/ |
