sika1970
Bonsoir,
j'essaie d'installé gnome-python-extras a partir d'une archive tar.bz2.
Dans /usr/local j'ai crée un répertoire gnome-python-extra. première question est ce bon endroit pour installer un programme provenant d'une archive ?
Lors de l'installation quand je fais ./configure j'ai le message d'erreur suivant :
[root@localhost gnome-python-extras-2.14.2]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnuoldld
checking host system type... i686-pc-linux-gnuoldld
checking for style of include used by make... GNU
checking for gcc... no
checking for cc... no
checking for cc... no
checking for cl... no
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details.
je ne comprends pas trop se que je dois faire pour ne plus avoir cette erreur ( jai lu le fichier config.log mais sa ne me parle pas), est ce que je dois installer un compileur C ? Si oui lequel me conseillez vous et où le trouver ?
merci d'avance pour vos futurs réponses.
Pikachu_2014
Salut,
- ce que tu cherches à compiler existe déjà en paquetage : gnome-python2-extras (yum install gnome-python2-extras) ;
- si tu as néanmoins l'intention de compiler, il te manque le compilateur C gcc (yum install gcc), et aussi quelques autres outils de développement pour la suite (dans pirut, cocher le groupe «Développement») ;
- petite remarque : ne jamais compiler en root ; seulement passer en root au moment de l'installation.
sika1970
Une fois de plus merci à toi Pikachu_2014 ( il me semble que tu as apporté une réponse à chacune de mes questions),
j'ai essayé avec yum avant de tenter une installation manuelle, mais je cherchais gnome-python-extras .
"petite remarque : ne jamais compiler en root ; seulement passer en root au moment de l'installation." :oops: j'ai oublié de repasser en $ après avoir crée un dossier dans /usr/local.
Juste pour ma culture linuxienne, quels sont les risques d'une compilation en root ?
Pikachu_2014
I'm going to tell you a secret : je n'en sais rien !
On m'a toujours rabâché que ce n'était pas bien, et certaines rumeurs disent que Linus Thorvald en personne dit que ce n'est pas bien de compiler en root !
Plus sérieusement, je suppose qu'il peut se glisser des commandes «malicieuses» dans le Makefile (pas volontaires, à la suite d'une erreur/inattention du/des programmeur(s) non corrigée, ou une blague en GPL du style «rm -rf /» :-D), et que lancer un tel Makefile plombé n'affectera pas les répertoires système en tant que simple utilisateur (et sera donc détecté par un message d'erreur : «sorry but I can't remove / because you are only a simple user :-D»).
Pour gnome-python2-extras : je me suis fait avoir de la même façon que toi, mais trouvant «bizarre» qu'un gnome-python-extras (pourtant assez «commun») ne soit pas dispo. dans base ou extras, une recherche dans rpm.pbone.net à partir des noms des fichiers de l'archive m'avait permis de découvrir le «bon» nom du paquetage dans Fedora.
kwizart
J'ai expérimenté cela récemment en compilant un utilitaire:
Je compile en utilisant rpmbuild dans un compte dédié. Lorsque j'ai essayé la première fois (au make install) le makefile a essayé d'installer ces fichiers dans /usr/sbin/ etc... hors dans ce processus, il aurait du les installer dans le repertoire buildroot soit /var/tmp/mon_package_rpm-root/usr/sbin pour le packaging rpm...
Donc le processus a été bloqué...
Pikachu_2014
Comme quoi c'est 'achement utile un compte dédié pour builder !
De mon temps, on faisait ça dans /usr/src/redhat, à la fortune du pot :-D : ou tu écrivais du premier coup un safe .spec, ou alors...
sika1970
Je n'ai pas oublié de revenir simple utilisateur lorsque j'ai tenté une compilation en root, je n'ai pas les droits d'écriture dans usr/local, il faudra que je change ça.
J'ai installé gnome-python2-extras mais listen veux gnome-python-extras ( sans le 2), j'ai donc installé gcc. Un nouveau ./configure et une nouvelle erreur :
[Jean-Marc@localhost gnome-python-extra]$ cd gnome-python-extras-2.14.2
[Jean-Marc@localhost gnome-python-extras-2.14.2]$ ./configure
./configure: line 1291: config.log: Permission denied
[Jean-Marc@localhost gnome-python-extras-2.14.2]$ su -
Mot de passe :
[root@localhost ~]# cd /usr/local/gnome-python-extra/gnome-python-extras-2.14.2
[root@localhost gnome-python-extras-2.14.2]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking dependency style of g++... none
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
appending configuration tag "F77" to libtool
checking for a Python interpreter with version >= 2.3... python
checking for python... /usr/bin/python
checking for python version... 2.4
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.4/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.4/s ite-packages
checking for headers required to compile python extensions... not found
configure: error: could not find Python headers
[root@localhost gnome-python-extras-2.14.2]#
il manque encore quelque chose. je pense que je vais laisser tomber et rechercher un autre programme pour gerer ma musique.
Pikachu_2014
Re-salut,
listen c'est vraiment --- pardonne ma vulgarité --- trop la m*** à installer à partir des sources (il m'a fallu deux semaines pour en venir à bout, y compris celles passées pendant les heures de travail à dépatouiller le tout au lieu de bosser, mais chuuut !).
Je sais qu'un des membres de ce forum en a fait un paquet (avec les dépendances qui vont bien), mais je ne me rappelle plus qui. Je crois même qu'il va rentrer incessament sous peu dans Extras (ou du moins c'est en instance, me semble-t-il).
Conseil d'ami : renonce et essaie de retrouver les paquets, contente-toi d'amarok, ou si tu n'aimes pas KDE, de rhythmbox, muine ou banshee.
ÉDIT : Pour l'erreur, normalement on doit pouvoir spécifier le chemin des extras à lire (ou au pire bidouiller le ./configure pour), mais je ne sais plus, je ne replongerais plus jamais dans listen !
sika1970
Si il t'a fallu deux semaines pour en venir a bout, je laisse tomber ( j'ai pas envie d'y passer des mois, de poser moult questions sur ce forum et certainement finir la compilation quand il serra dispo via yum :-D ).
Je garde amarok pour l'instant.
Bonne fin de soirée à toi.
ps : dommage que je ne puisse pas mettre abandonné au lieux de résolu
:-D
Sat
C'est moi qui empaquete Listen pour Extras, et c'est loin d'être ma première priorité.
Je confirme, Listen c'est n'importe quoi, une bonne partie du code provient de Quod Libet, le système de build de la branche 0.4.x est immonde, à croire que le dev se fout que son machin tourne ailleurs que sous Ubuntu, d'ailleurs il a fait une pre-release, disponible uniquement en deb binaire, pas de tarball des sources.
Sinon, point positif, le système de build de la branche de dev s'est amélioré, ça passe sans soucis maintenant, le path est encore hardcodé, pas de cible uninstall pour make, le programme ne se lance pas à cause d'une erreur triviale.
je vous conseille d'utilise Quod Libet, il est plus stable, il a plus de fonctionnalités, un paquet est en cours de revue, l'ayant testé, ça marche bien.
Quand à Listen, j'essayerais de pousser une pre-release, je dois d'abord pousser une nouvelle dépendance python-sexy -c'est presque fini-
Pikachu_2014
Merci pour l'info. sur Quod Libet, je compilerai ça avec plaisir.
Enfin quelqu'un qui a vu autre chose que de jolies prises d'écrans de listen :-D
[size=xx-small]
(c'est vrai, pardon au dév. de Listen, mais j'en ai même fait un cauchemar de listen, je crois que je travaillais trop dessus à l'époque...)
[/size]
