Voila j'ai voulu compiler des truc mais ça marche pas. Quand je fais
sh ./configure j'ai ça:
gg@suse:~/download/gaim-vv-1.2.0> sh ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
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 for sed... /usr/bin/sed
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Quand je ragarde dans config.log:
## ----------- ##
## Core tests. ##
## ----------- ##
configure:1602: checking build system type
configure:1620: result: i686-pc-linux-gnu
configure:1628: checking host system type
configure:1642: result: i686-pc-linux-gnu
configure:1650: checking target system type
configure:1664: result: i686-pc-linux-gnu
configure:1694: checking for a BSD-compatible install
configure:1749: result: /usr/bin/install -c
configure:1760: checking whether build environment is sane
configure:1803: result: yes
configure:1868: checking for gawk
configure:1884: found /bin/gawk
configure:1894: result: gawk
configure:1904: checking whether make sets $(MAKE)
configure:1924: result: yes
configure:2097: checking for sed
configure:2115: found /bin/sed
configure:2127: result: /bin/sed
configure:2187: checking for gcc
configure:2203: found /usr/bin/gcc
configure:2213: result: gcc
configure:2457: checking for C compiler version
configure:2460: gcc --version </dev/null >&5
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:2463: $? = 0
configure:2465: gcc -v </dev/null >&5
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
configure:2468: $? = 0
configure:2470: gcc -V </dev/null >&5
gcc: `-V' option must have argument
configure:2473: $? = 1
configure:2496: checking for C compiler default output file name
configure:2499: gcc conftest.c >&5
configure:2502: $? = 0
configure:2548: result: a.out
configure:2553: checking whether the C compiler works
configure:2559: ./a.out
./configure: line 2560: ./a.out: Permission denied
configure:2562: $? = 126
configure:2571: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Ca vient de quoi au juste. Je débute doucement alors ne vous foutez pas de
moi. J'arrive à faire la même chose avec Ubuntu et ça marche.
--
Le Sun, 24 Jul 2005 13:12:27 +0200, Gerald Rochat a écrit :
Salut, Bonjour
Voila j'ai voulu compiler des truc mais ça marche pas. Quand je fais sh ./configure j'ai ça: [...]
Quand je ragarde dans config.log: [...] ./configure: line 2560: ./a.out: Permission denied
Visiblement tu n'as pas le droit d'écrire sur la lib où tu compiles.
lhabert
Gerald Rochat :
configure:2499: gcc conftest.c >&5 configure:2502: $? = 0 configure:2548: result: a.out configure:2553: checking whether the C compiler works configure:2559: ./a.out ./configure: line 2560: ./a.out: Permission denied
Le script configure a écrit un programme C trivial dans le fichier « conftest.c », et a ensuite appelé le compilateur C (gcc) dessus pour le compiler (étonnant, non?). Apparament, la compilation a réussi, puisque le compilateur a renvoyé 0 comme code de retour (tout programme lorsqu'il se termine renvoie en résultat un nombre au programme qui l'a lancé, et la convention universelle veut que quand tout s'est bien passé, l'on renvoie 0, et, si il y a eu un problème on renvoie un entier non nul). Le compilateur C, quand on ne lui spécifie pas un nom de fichier dans lequel mettre le programme produit, le met dans le fichier « a.out ». Le configure essaye donc d'exécuter le a.out produit a l'étape précédente (ligne 2559). Et là, il se prend un permission denied. Je vois deux explications possibles : - la permission d'exécution n'est pas activée sur le a.out (cela voudrait dire que le compilo déconne gravement) - le système de fichiers dans lequel tu es est monté avec l'option « noexec », qui interdit d'exécuter des programmes situés sur lui.
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est plus simple de rebooter). Par exemple, pour une ligne :
. Si tu as juste « noexec » comme option, remplace par « defaults ».
Gerald Rochat :
configure:2499: gcc conftest.c >&5
configure:2502: $? = 0
configure:2548: result: a.out
configure:2553: checking whether the C compiler works
configure:2559: ./a.out
./configure: line 2560: ./a.out: Permission denied
Le script configure a écrit un programme C trivial dans le fichier
« conftest.c », et a ensuite appelé le compilateur C (gcc) dessus pour le
compiler (étonnant, non?). Apparament, la compilation a réussi, puisque le
compilateur a renvoyé 0 comme code de retour (tout programme lorsqu'il se
termine renvoie en résultat un nombre au programme qui l'a lancé, et la
convention universelle veut que quand tout s'est bien passé, l'on renvoie 0,
et, si il y a eu un problème on renvoie un entier non nul). Le compilateur
C, quand on ne lui spécifie pas un nom de fichier dans lequel mettre le
programme produit, le met dans le fichier « a.out ». Le configure essaye
donc d'exécuter le a.out produit a l'étape précédente (ligne 2559). Et là,
il se prend un permission denied. Je vois deux explications possibles :
- la permission d'exécution n'est pas activée sur le a.out (cela voudrait
dire que le compilo déconne gravement)
- le système de fichiers dans lequel tu es est monté avec l'option
« noexec », qui interdit d'exécuter des programmes situés sur lui.
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab
pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre
la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est
plus simple de rebooter). Par exemple, pour une ligne :
configure:2499: gcc conftest.c >&5 configure:2502: $? = 0 configure:2548: result: a.out configure:2553: checking whether the C compiler works configure:2559: ./a.out ./configure: line 2560: ./a.out: Permission denied
Le script configure a écrit un programme C trivial dans le fichier « conftest.c », et a ensuite appelé le compilateur C (gcc) dessus pour le compiler (étonnant, non?). Apparament, la compilation a réussi, puisque le compilateur a renvoyé 0 comme code de retour (tout programme lorsqu'il se termine renvoie en résultat un nombre au programme qui l'a lancé, et la convention universelle veut que quand tout s'est bien passé, l'on renvoie 0, et, si il y a eu un problème on renvoie un entier non nul). Le compilateur C, quand on ne lui spécifie pas un nom de fichier dans lequel mettre le programme produit, le met dans le fichier « a.out ». Le configure essaye donc d'exécuter le a.out produit a l'étape précédente (ligne 2559). Et là, il se prend un permission denied. Je vois deux explications possibles : - la permission d'exécution n'est pas activée sur le a.out (cela voudrait dire que le compilo déconne gravement) - le système de fichiers dans lequel tu es est monté avec l'option « noexec », qui interdit d'exécuter des programmes situés sur lui.
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est plus simple de rebooter). Par exemple, pour une ligne :
. Si tu as juste « noexec » comme option, remplace par « defaults ».
Gerald Rochat
Salut, Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est plus simple de rebooter). Par exemple, pour une ligne :
Pas de noexec. le fichiers se trouve dans mon dossier perso (sur /home/gg) --
Amicalement, Gg.
Salut,
Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab
pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre
la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est
plus simple de rebooter). Par exemple, pour une ligne :
Salut, Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est plus simple de rebooter). Par exemple, pour une ligne :
Pas de noexec. le fichiers se trouve dans mon dossier perso (sur /home/gg) --
Amicalement, Gg.
Nicolas S.
Salut, Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est plus simple de rebooter). Par exemple, pour une ligne :
Pas de noexec. le fichiers se trouve dans mon dossier perso (sur /home/gg)
Il y a peut-être un problème d'accès au fichier à cause des ACL...
-- Nicolas S.
Salut,
Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab
pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre
la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est
plus simple de rebooter). Par exemple, pour une ligne :
Salut, Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est plus simple de rebooter). Par exemple, pour une ligne :
Pas de noexec. le fichiers se trouve dans mon dossier perso (sur /home/gg)
Il y a peut-être un problème d'accès au fichier à cause des ACL...
-- Nicolas S.
Nicolas S.
Salut, Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est plus simple de rebooter). Par exemple, pour une ligne :
Pas de noexec. le fichiers se trouve dans mon dossier perso (sur /home/gg)
Il y a peut-être un problème d'exécution du fichier à cause des ACL...
-- Nicolas S.
Salut,
Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab
pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre
la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est
plus simple de rebooter). Par exemple, pour une ligne :
Salut, Le Dimanche 24 Juillet 2005 14:01, Luc Habert écrivait:
Je penche plutôt pour la deuxième hypothèse. Regarde le fichier /etc/fstab pour voir si tu as des « noexec » dedans. Si oui, enlève les, et redémarre la machine (on devrait pouvoir s'en tirer en remontant les fs, mais c'est plus simple de rebooter). Par exemple, pour une ligne :
Pas de noexec. le fichiers se trouve dans mon dossier perso (sur /home/gg)
Il y a peut-être un problème d'exécution du fichier à cause des ACL...
-- Nicolas S.
lhabert
Gerald Rochat :
Pas de noexec.
Certes, mais le « acl,user_xattr » doit pouvoir cacher bien des horreurs. Pour en avoir le coeur net, crée dans le même répertoire un fichier nommé « ploum », contenant ceci :
#!/bin/sh
echo plam
, puis lance la commande :
chmod 755 ploum
, et enfin :
./ploum
. Si ça te dit « permission denied », c'est bien un problème de paranoification à la noix sans doute liée à « user_xattr » (mais je ne connais pas du tout ce truc, donc je sais pas vraiment en fait).
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask » ?
Gerald Rochat :
Pas de noexec.
Certes, mais le « acl,user_xattr » doit pouvoir cacher bien des horreurs.
Pour en avoir le coeur net, crée dans le même répertoire un fichier nommé
« ploum », contenant ceci :
#!/bin/sh
echo plam
, puis lance la commande :
chmod 755 ploum
, et enfin :
./ploum
. Si ça te dit « permission denied », c'est bien un problème de
paranoification à la noix sans doute liée à « user_xattr » (mais je ne
connais pas du tout ce truc, donc je sais pas vraiment en fait).
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask » ?
Certes, mais le « acl,user_xattr » doit pouvoir cacher bien des horreurs. Pour en avoir le coeur net, crée dans le même répertoire un fichier nommé « ploum », contenant ceci :
#!/bin/sh
echo plam
, puis lance la commande :
chmod 755 ploum
, et enfin :
./ploum
. Si ça te dit « permission denied », c'est bien un problème de paranoification à la noix sans doute liée à « user_xattr » (mais je ne connais pas du tout ce truc, donc je sais pas vraiment en fait).
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask » ?
Gerald Rochat
Salut, Le Dimanche 24 Juillet 2005 15:38, Luc Habert écrivait:
./ploum
bash: ./ploum: /bin/sh: bad interpreter: Permission non accordée si je fait sh ploum ça marche.
. Si ça te dit « permission denied », c'est bien un problème de paranoification à la noix sans doute liée à « user_xattr » (mais je ne connais pas du tout ce truc, donc je sais pas vraiment en fait).
et si je vire acl,user_xattr je risque quoi? D'ailleur c'est quoi?
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask »
0022 --
Amicalement, Gg.
Salut,
Le Dimanche 24 Juillet 2005 15:38, Luc Habert écrivait:
./ploum
bash: ./ploum: /bin/sh: bad interpreter: Permission non accordée
si je fait sh ploum ça marche.
. Si ça te dit « permission denied », c'est bien un problème de
paranoification à la noix sans doute liée à « user_xattr » (mais je ne
connais pas du tout ce truc, donc je sais pas vraiment en fait).
et si je vire acl,user_xattr je risque quoi?
D'ailleur c'est quoi?
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask »
Salut, Le Dimanche 24 Juillet 2005 15:38, Luc Habert écrivait:
./ploum
bash: ./ploum: /bin/sh: bad interpreter: Permission non accordée si je fait sh ploum ça marche.
. Si ça te dit « permission denied », c'est bien un problème de paranoification à la noix sans doute liée à « user_xattr » (mais je ne connais pas du tout ce truc, donc je sais pas vraiment en fait).
et si je vire acl,user_xattr je risque quoi? D'ailleur c'est quoi?
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask »
0022 --
Amicalement, Gg.
lhabert
Gerald Rochat :
bash: ./ploum: /bin/sh: bad interpreter: Permission non accordée
Bon, ça confirme que ce n'est pas la faute au compilateur.
si je fait sh ploum ça marche.
Normal : le système te laisse exécuter les programmes venant avec la distrib (encore heureux).
et si je vire acl,user_xattr je risque quoi?
Je pense que ça ne peut qu'améliorer les choses. De toutes manières, tu pourras toujours le remettre si ça casse tout.
D'ailleur c'est quoi?
Les ACL, c'est un système permettant de gérer plus finement les permissions sur les fichiers (par exemple, de les définir utilisateur par utilisateur, tandis que le système unix traditionel ne permet que de définir les permissions pour le propriétaire, le groupe propriétaire, et les autres). Ça se manipule avec « getfacl » et « setfacl ». Je suppose que l'option de montage sert à activer les ACL.
Le « user_xattr », là, j'en sais vraiment rien, et la page de man n'explique rien. Enfin le nom laisse subhodorer que c'est le coupable.
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask »
0022
Donc c'est pas ça. Je m'étais dit que ça aurait pu être « 0122 », ce qui aurait eu pour effet que le a.out aurait été créé sans la permission d'exécution.
Gerald Rochat :
bash: ./ploum: /bin/sh: bad interpreter: Permission non accordée
Bon, ça confirme que ce n'est pas la faute au compilateur.
si je fait sh ploum ça marche.
Normal : le système te laisse exécuter les programmes venant avec la distrib
(encore heureux).
et si je vire acl,user_xattr je risque quoi?
Je pense que ça ne peut qu'améliorer les choses. De toutes manières, tu
pourras toujours le remettre si ça casse tout.
D'ailleur c'est quoi?
Les ACL, c'est un système permettant de gérer plus finement les permissions
sur les fichiers (par exemple, de les définir utilisateur par utilisateur,
tandis que le système unix traditionel ne permet que de définir les
permissions pour le propriétaire, le groupe propriétaire, et les autres). Ça
se manipule avec « getfacl » et « setfacl ». Je suppose que l'option de
montage sert à activer les ACL.
Le « user_xattr », là, j'en sais vraiment rien, et la page de man n'explique
rien. Enfin le nom laisse subhodorer que c'est le coupable.
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask »
0022
Donc c'est pas ça. Je m'étais dit que ça aurait pu être « 0122 », ce qui
aurait eu pour effet que le a.out aurait été créé sans la permission
d'exécution.
bash: ./ploum: /bin/sh: bad interpreter: Permission non accordée
Bon, ça confirme que ce n'est pas la faute au compilateur.
si je fait sh ploum ça marche.
Normal : le système te laisse exécuter les programmes venant avec la distrib (encore heureux).
et si je vire acl,user_xattr je risque quoi?
Je pense que ça ne peut qu'améliorer les choses. De toutes manières, tu pourras toujours le remettre si ça casse tout.
D'ailleur c'est quoi?
Les ACL, c'est un système permettant de gérer plus finement les permissions sur les fichiers (par exemple, de les définir utilisateur par utilisateur, tandis que le système unix traditionel ne permet que de définir les permissions pour le propriétaire, le groupe propriétaire, et les autres). Ça se manipule avec « getfacl » et « setfacl ». Je suppose que l'option de montage sert à activer les ACL.
Le « user_xattr », là, j'en sais vraiment rien, et la page de man n'explique rien. Enfin le nom laisse subhodorer que c'est le coupable.
Ah, en fait, il y a une autre possibilité. Que donne la commande « umask »
0022
Donc c'est pas ça. Je m'étais dit que ça aurait pu être « 0122 », ce qui aurait eu pour effet que le a.out aurait été créé sans la permission d'exécution.
