2009-05-24 8 views
2

J'essaye de construire Python 2.6.2 depuis la source sur mon système Linux. Il a ncurses installé sur/usr/local/et curses.h sur/usr/local/include/ncurses. Donc, curses.h n'est pas trouvé sur le chemin d'inclusion, et ces paquets échouent dans la construction Python.Compilation de Python, curses.h pas trouvé

Quelle est la bonne solution à cela? Est-ce que Python est censé inclure < ncurses/curses.h>? Est-ce que/usr/local/include/ncurses doit être dans le chemin include? Devrait-il y avoir un lien entre les fichiers du répertoire ncurses et/usr/local/include?

Ou existe-t-il une solution plus simple?

Répondre

5

Avec beaucoup de paquets Open Source, vous pouvez définir:

export CPPFLAGS="-I/usr/local/include" 

ou même:

export CPPFLAGS="-I/usr/local/include/ncurses" 

avant d'exécuter le script de configuration. Je n'ai pas compilé Python assez récemment pour être sûr que cela fonctionne, mais c'est probablement le cas - j'ai des ncurses installés sous/usr/gnu (car/usr/local/est monté automatiquement et contient des antiquités) et je ne me souviens pas d'avoir à utiliser quelque chose de spécial pour le faire fonctionner.


revérifié ...

Le script de configuration ne comprend que <curses.h>. J'ai dû utiliser:

export CPPFLAGS="-I/usr/gnu/include -I/usr/gnu/include/ncurses" 
export LDFLAGS="-L/usr/gnu/lib" 
./configure 

Pour obtenir la configuration de Python (2.5) pour accepter les malédictions. Vous devez remplacer "gnu" par "local" pour votre configuration.

+0

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

0

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:

  1. 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.

+1

Il existe des différences entre les en-têtes, par exemple 'sizeof (WINDOW)' lors de la comparaison de ncurses/ncursesw. Et bien sûr, ncurses5/ncurses6 utilise différents masques de bits pour la souris. –

+0

@ThomasDickey J'évaluais simplement la compatibilité, pas l'identité. Apparemment, la page de manuel indique que les en-têtes sont compatibles avec les sources. Peu importe, j'ai dépouillé ma réponse de cette information, car cela ne fait pas partie de la question. – farsil

Questions connexes