-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
panel.h is not found even if it's installed on various flavours of SUSE #56480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hello everybody, With the same build/compile command, I'm able to have "my" runing python version (2.6.x or 2.7.x) on IA64 server runing SLES 10 SP2/SP3,not on IA64 server runing SLES 11 SP1. I've try with 2.7, 2.7.1 and 2.7.2rc1 version without success. On both configuration types, I've installed all the available libraries, but on SLES 11 SP1, the make resulting message is the following (the complete building messages are in the joined gzip text file): ------------------ Failed to build these modules: running build_scripts Any advice will be welcome. Thanks a lot for your attention and your process. All the best, Vincent |
panel.h is not found. You'll need to install the package that error: panel.h: No such file or directory This does not look like a Python bug, so I'll set the issue to |
Hello Stefan, Thanks a lot for your time and answer, but here are some additional information regarding the requires "panel.h" file. I've just launched a find command onto my ia64 server, and here is the result: hesione:/ # find / -name "panel.h" As you may have also observed, the build command is claiming also ncurses, which is installed. hesione:~ # rpm -qa|grep ncurses Any further information will be welcome. Thanks again for your patience, time and answer. All the best, Vincent |
I just stumbled upon the same problem with Python 2.7.3 on SLES 11 SP1 amd64. Obviously, SuSE puts the needed header file into /usr/include/ncurses/, and one can either create a symlink in /usr/include/ or apply a patch to _curses_panel.c: --- Modules/_curses_panel.c.orig 2012-05-23 13:34:17.000000000 +0200
+++ Modules/_curses_panel.c 2012-05-23 13:34:27.000000000 +0200
@@ -14,7 +14,7 @@
#include "py_curses.h"
-#include <panel.h>
+#include <ncurses/panel.h>
static PyObject *PyCursesError;
Maybe some logic could be put into the build process to automatically handle this? Apparently, configure already knows about the different locations... Regards, |
The same happens on OpenSUSE 12.1 so Python can't be fully built there which is a bit of a shame. OpenSUSE uses this patch for their packages, but that would break other distributions so it's not a good solution: Here's a list of all curses related files in /usr/include on my OpenSUSE 12.1: If we look just for panel.h we get: There is some specific code that appends '/usr/include/ncursesw' to the include list in setup.py but that doesn't get triggered here because curses_library == 'ncurses' because readline is built against that. The attached patch makes it build and the curses tests pass but it feels kind of hack-ish. panel.h is there so Python should find it somehow therefore this is a genuine bug. Ideas for a better solution? |
I have created a simple patch that solves this problem. Depending on whether panel.h or ncurses/panel.h are found, the appropriate one is included. |
Removed generated files from patch. Requesting review. |
hard coding ncurses seems to be wrong, as in most cases, you do want ncursesw. |
I have been hit by the same issue today. |
This seems not so easily patched for Python 3.12 The configure script uses pkg-config, but only if it finds
|
My knowledge of configure scripts is not sufficient to fix this properly, but the following patch seems to work Either:
|
I suggest to use the tool
or specially for libpanel or libpanelw
or for forms
|
Yes, this seems non-optimal. I think we should run the pkg-config check for panel/panelw before we try to find panel.h. |
> The configure script uses pkg-config, but [only if it finds `panel.h`](https://github.com/python/cpython/blob/0fb18b02c8ad56299d6a2910be0bab8ad601ef24/configure.ac#L6443), even though pkg-config would help find where panel.h actually is
Yes, this seems non-optimal. I think we should run the pkg-config check for panel/panelw before we try to find panel.h.
Shouldn’t the logic be just other way around? We test for pkg-config provided configuration and only then we can try some hard-written values, whether they could work?
|
Unfortunately Python 3.6 doesn't include all autoconfig infrastructure required for the upstream solution, so we have to directly patch Modules/_curses_panel.c Discussion still continue on gh#python#56480.
Unfortunately Python 3.6 doesn't include all autoconfig infrastructure required for the upstream solution, so we have to directly patch Modules/_curses_panel.c Discussion still continue on gh#python#56480. Patch: python-3.3.0b1-curses-panel.patch
Unfortunately Python 3.6 doesn't include all autoconfig infrastructure required for the upstream solution, so we have to directly patch Modules/_curses_panel.c Discussion still continues on gh#python#56480. Patch: python-3.3.0b1-curses-panel.patch
Unfortunately Python 3.6 doesn't include all autoconfig infrastructure required for the upstream solution, so we have to directly patch Modules/_curses_panel.c Discussion still continues on gh#python#56480. Patch: python-3.3.0b1-curses-panel.patch
Just to help any SUSE users who are still having this problem... I noticed it today and after reading the installation documentation and having a chat with Google Gemini :-) we came up with the following workaround: setting the CPPFLAGS parameter to "-I/usr/include/ncurses" before executing "configure" and the ncurses library was found correctly. This is a useful workaround until a more permanent change is decided upon. |
On 2025/02/06 16:56:34 -0800, duncreg wrote:
I noticed this problem today on OpenSUSE Tumbleweed when compiling Python from scratch and after examining the Python installation docs and then having a very helpful chat with Google Gemini :-) we tried this:
setting the environment variable CPPFLAGS to "-I/usr/include/ncurses" before executing the Python source's configure command
and it found the panel.h file just fine after that, no need to patch anything.
Use the tool pkgconf(1) ... e.g.
pkgconf --cflags ncursesw
pkgconf --libs ncursesw
to get CFLAGS for compiling as well as LIBS for linkage of the wide character
version of (lib)ncurses. Beside pkg-conf there is also the script
ncursesw6-config(1) which is also part of the package ncurses-devel
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: