Je sais que c'est une très vieille question, mais le problème m'est toujours apparu lors de la compilation de Python 3.6.0 à partir de la source, donc je suppose que c'est toujours pertinent.
Les versions récentes de ncurses sont disponibles en plusieurs versions: normale, prise en charge des caractères larges, threadée. Afin de permettre aux programmeurs de conserver et d'utiliser des saveurs différentes, en plus de nommer différemment les bibliothèques (ncursesw.so
, ncursest.so
, etc.), le script configure ncurses configure le makefile pour placer les fichiers d'en-tête dans les sous-répertoires par défaut. Cela permet également d'avoir différentes implémentations curses aux côtés de ncurses, comme spécifié dans le man page.
Certains programmes, cependant, supposent toujours que curses.h
, le long de tous les autres en-têtes ncurses, sont placés dans les chemins d'accès de recherche de niveau supérieur et ne regarderont pas dans les sous-répertoires. Dans de nombreuses distributions linux il y a généralement une sorte de solution pour le problème dans les paquets de developement ncurses, mais si vous compilez ncurses de la source, il y a deux approches possibles pour résoudre le problème:
- En utilisant
CPPFLAGS
ou équivalent, la réponse acceptée suggère. Cela fonctionne, mais vous devez définir les indicateurs de compilation appropriés à chaque fois. Configuration des ncurses avec --enable-overwrite
. Cela installera les fichiers d'en-tête ncurses dans le répertoire d'inclusion de niveau supérieur, en fonction de votre --prefix
.
Si vous ne prévoyez pas d'installer une autre bibliothèque curses, il est tout à fait sûr de mettre les en-têtes ncurses dans le niveau supérieur include_path, et il est l'approche suivie par Gentoo.
Cela a fait l'affaire pour moi. J'ai essayé de paramétrer CFLAGS et ça n'a pas fonctionné, ça devait être CPPFLAGS. Et pour moi le LDFLAGS n'était pas nécessaire, car libncurses se trouve sur mon LD_LIBRARY_PATH d'accord. Je vous remercie! – Mojo