Je dois mal faire un truc c'est pas possible : quand je compile un truc
avec le trio infernale ./configure make et make install, le make install
ne crée pas les répertoires nécessaires. Lors du premier appel dans les
script ca crée un fichier et lors du deuxième ca se plante (normal du
coup). J'ai constaté le pb autant en 4.x qu'en 5.x. Je dois louper
quelque chose c'est pas possible que le script d'install ne teste pas
d'abord l'existence du répertoire et le crée au besoin, je n'ai jamais
eu ce pb sur euh disons un truc qui commence par li et finit par nux ...
Je dois mal faire un truc c'est pas possible : quand je compile un truc ^^^^^^^
C'est quoi « un truc » en vrai ? Sans cette information, le reste de votre article est incompréhensible.
-- olive
pornin
According to Fabrice :
Je dois mal faire un truc c'est pas possible : quand je compile un truc avec le trio infernal ./configure make et make install
Pour 99% des logiciels c'est déjà une erreur. La procédure normale est de passer par les ports (cf le handbook) qui ajuste tout ça comme il faut, et en plus (bonus !) fabrique des installations gérées par le système de packages, avec gestion des dépendances et tout ça. L'idée générale est que le port contient les patchs qui vont bien pour ne pas avoir de problème ; conceptuellement, ça mutualise le travail de portage.
Bon, sinon, pour le problème lui-même, ça peut être dû à une variable d'environnement qui ne plaît pas au script configure. Ce genre de script est très tâtillon ; j'ai déjà eu des ennuis avec une variable d'environnement nommée ARCH (que réglait ma config mais qui rentrait en conflit avec les scripts et Makefiles -- maintenant je l'appelle LOCALARCH).
je n'ai jamais eu ce pb sur euh disons un truc qui commence par li et finit par nux ...
Beaucoup de logiciel opensource sont annoncé comme tournant, supposément, sous tout Unix (via de l'autoconf), mais en fait ils ont été développés et testés sous Linux seulement. Il est normal que ça marche sous Linux, puisque c'est ce qu'utilise le développeur.
Le systèmes des ports BSD arrange pas mal les choses. Quand on utilise Solaris, la situation est pire.
--Thomas Pornin
According to Fabrice <f.bruelpasdepub@wanadoo.fr>:
Je dois mal faire un truc c'est pas possible : quand je compile un truc
avec le trio infernal ./configure make et make install
Pour 99% des logiciels c'est déjà une erreur. La procédure normale est
de passer par les ports (cf le handbook) qui ajuste tout ça comme il
faut, et en plus (bonus !) fabrique des installations gérées par le
système de packages, avec gestion des dépendances et tout ça. L'idée
générale est que le port contient les patchs qui vont bien pour ne
pas avoir de problème ; conceptuellement, ça mutualise le travail de
portage.
Bon, sinon, pour le problème lui-même, ça peut être dû à une variable
d'environnement qui ne plaît pas au script configure. Ce genre de
script est très tâtillon ; j'ai déjà eu des ennuis avec une variable
d'environnement nommée ARCH (que réglait ma config mais qui rentrait
en conflit avec les scripts et Makefiles -- maintenant je l'appelle
LOCALARCH).
je n'ai jamais eu ce pb sur euh disons un truc qui commence par li et
finit par nux ...
Beaucoup de logiciel opensource sont annoncé comme tournant,
supposément, sous tout Unix (via de l'autoconf), mais en fait ils ont
été développés et testés sous Linux seulement. Il est normal que ça
marche sous Linux, puisque c'est ce qu'utilise le développeur.
Le systèmes des ports BSD arrange pas mal les choses. Quand on utilise
Solaris, la situation est pire.
Je dois mal faire un truc c'est pas possible : quand je compile un truc avec le trio infernal ./configure make et make install
Pour 99% des logiciels c'est déjà une erreur. La procédure normale est de passer par les ports (cf le handbook) qui ajuste tout ça comme il faut, et en plus (bonus !) fabrique des installations gérées par le système de packages, avec gestion des dépendances et tout ça. L'idée générale est que le port contient les patchs qui vont bien pour ne pas avoir de problème ; conceptuellement, ça mutualise le travail de portage.
Bon, sinon, pour le problème lui-même, ça peut être dû à une variable d'environnement qui ne plaît pas au script configure. Ce genre de script est très tâtillon ; j'ai déjà eu des ennuis avec une variable d'environnement nommée ARCH (que réglait ma config mais qui rentrait en conflit avec les scripts et Makefiles -- maintenant je l'appelle LOCALARCH).
je n'ai jamais eu ce pb sur euh disons un truc qui commence par li et finit par nux ...
Beaucoup de logiciel opensource sont annoncé comme tournant, supposément, sous tout Unix (via de l'autoconf), mais en fait ils ont été développés et testés sous Linux seulement. Il est normal que ça marche sous Linux, puisque c'est ce qu'utilise le développeur.
Le systèmes des ports BSD arrange pas mal les choses. Quand on utilise Solaris, la situation est pire.
--Thomas Pornin
Fabrice
* Fabrice (Mon, 20 Dec 2004 13:38:31 +0100):
Je dois mal faire un truc c'est pas possible : quand je compile un truc
^^^^^^^ C'est quoi « un truc » en vrai ? Sans cette information, le reste de votre article est incompréhensible.
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les
outils userland, je fais : #cd altq-3.1 #make #make install et là ca part en vrille : comme je fais cette install sur une 4.9 Release from scratch, /usr/local est vide et donc l'install se banane sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère d'avoir à se palucher l'arborescence à la main.
Bon je cite altq mais il y en a plein d'autres...
FABrice
* Fabrice <f.bruelpasdepub@wanadoo.fr> (Mon, 20 Dec 2004 13:38:31 +0100):
Je dois mal faire un truc c'est pas possible : quand je compile un truc
^^^^^^^
C'est quoi « un truc » en vrai ? Sans cette information, le reste de
votre article est incompréhensible.
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les
outils userland, je fais :
#cd altq-3.1
#make
#make install
et là ca part en vrille : comme je fais cette install sur une 4.9
Release from scratch, /usr/local est vide et donc l'install se banane
sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère
d'avoir à se palucher l'arborescence à la main.
Je dois mal faire un truc c'est pas possible : quand je compile un truc
^^^^^^^ C'est quoi « un truc » en vrai ? Sans cette information, le reste de votre article est incompréhensible.
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les
outils userland, je fais : #cd altq-3.1 #make #make install et là ca part en vrille : comme je fais cette install sur une 4.9 Release from scratch, /usr/local est vide et donc l'install se banane sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère d'avoir à se palucher l'arborescence à la main.
Bon je cite altq mais il y en a plein d'autres...
FABrice
Ralph-
Fabrice wrote:
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les outils userland, je fais : #cd altq-3.1 #make #make install et là ca part en vrille : comme je fais cette install sur une 4.9 Release from scratch, /usr/local est vide et donc l'install se banane sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère d'avoir à se palucher l'arborescence à la main.
Bon je cite altq mais il y en a plein d'autres...
FABrice
Bien bien.. alors quelques points à connaitre: 1) il y a make et make.. le make de FreeBSD est le make BSD (logique jusque la!). Le make peut etre aussi GNU, et dans la plupart des ports, on a droit a celui-la, qui est gmake sous FreeBSD et qui s'installe par les ports. 2) pas mal de programmes sous developpés sous Linux et parfois sont malheureusement tres dependant de la distro. Combien de fois, j'ai vu le ./configure && make && make install se vautrer d'une distro à l'autre, alors sous BSD (avec le mauvais make) ..
Fabrice wrote:
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les
outils userland, je fais :
#cd altq-3.1
#make
#make install
et là ca part en vrille : comme je fais cette install sur une 4.9
Release from scratch, /usr/local est vide et donc l'install se banane
sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère
d'avoir à se palucher l'arborescence à la main.
Bon je cite altq mais il y en a plein d'autres...
FABrice
Bien bien.. alors quelques points à connaitre:
1) il y a make et make.. le make de FreeBSD est le make BSD (logique
jusque la!). Le make peut etre aussi GNU, et dans la plupart des
ports, on a droit a celui-la, qui est gmake sous FreeBSD et qui
s'installe par les ports.
2) pas mal de programmes sous developpés sous Linux et parfois sont
malheureusement tres dependant de la distro. Combien de fois, j'ai
vu le ./configure && make && make install se vautrer d'une distro
à l'autre, alors sous BSD (avec le mauvais make) ..
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les outils userland, je fais : #cd altq-3.1 #make #make install et là ca part en vrille : comme je fais cette install sur une 4.9 Release from scratch, /usr/local est vide et donc l'install se banane sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère d'avoir à se palucher l'arborescence à la main.
Bon je cite altq mais il y en a plein d'autres...
FABrice
Bien bien.. alors quelques points à connaitre: 1) il y a make et make.. le make de FreeBSD est le make BSD (logique jusque la!). Le make peut etre aussi GNU, et dans la plupart des ports, on a droit a celui-la, qui est gmake sous FreeBSD et qui s'installe par les ports. 2) pas mal de programmes sous developpés sous Linux et parfois sont malheureusement tres dependant de la distro. Combien de fois, j'ai vu le ./configure && make && make install se vautrer d'une distro à l'autre, alors sous BSD (avec le mauvais make) ..
Fabrice
Fabrice wrote:
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les outils userland, je fais : #cd altq-3.1 #make #make install et là ca part en vrille : comme je fais cette install sur une 4.9 Release from scratch, /usr/local est vide et donc l'install se banane sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère d'avoir à se palucher l'arborescence à la main.
Bon je cite altq mais il y en a plein d'autres...
FABrice
Bien bien.. alors quelques points à connaitre: 1) il y a make et make.. le make de FreeBSD est le make BSD (logique jusque la!). Le make peut etre aussi GNU, et dans la plupart des ports, on a droit a celui-la, qui est gmake sous FreeBSD et qui s'installe par les ports. Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en
théorie pas à des années lumières de Free...
FAbrice
Fabrice wrote:
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les
outils userland, je fais :
#cd altq-3.1
#make
#make install
et là ca part en vrille : comme je fais cette install sur une 4.9
Release from scratch, /usr/local est vide et donc l'install se banane
sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère
d'avoir à se palucher l'arborescence à la main.
Bon je cite altq mais il y en a plein d'autres...
FABrice
Bien bien.. alors quelques points à connaitre:
1) il y a make et make.. le make de FreeBSD est le make BSD (logique
jusque la!). Le make peut etre aussi GNU, et dans la plupart des
ports, on a droit a celui-la, qui est gmake sous FreeBSD et qui
s'installe par les ports.
Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en
Dernier en date altq. Le patch du noyau, pas de pb. Pour compiler les outils userland, je fais : #cd altq-3.1 #make #make install et là ca part en vrille : comme je fais cette install sur une 4.9 Release from scratch, /usr/local est vide et donc l'install se banane sur /usr/local/bin sbin/ man/ man/man1 etc bref c'est bien galère d'avoir à se palucher l'arborescence à la main.
Bon je cite altq mais il y en a plein d'autres...
FABrice
Bien bien.. alors quelques points à connaitre: 1) il y a make et make.. le make de FreeBSD est le make BSD (logique jusque la!). Le make peut etre aussi GNU, et dans la plupart des ports, on a droit a celui-la, qui est gmake sous FreeBSD et qui s'installe par les ports. Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en
théorie pas à des années lumières de Free...
FAbrice
espie
In article , Fabrice wrote:
Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en théorie pas à des années lumières de Free...
Si je ne me gourre pas, altq est un projet independant, il me semble que son/ses auteur(s) sont affilies avec kame.
D'ailleurs, nous on a une spec pour mtree pour /usr/local, et on ne laisse jamais rien se compiler sans remplir /usr/local.
S'attendre a ce que tout marche avec un /usr/local vide releve de la gageure. J'ai du mal a croire que FreeBSD n'ait pas un equivalent quelque part et qu'il ne fasse pas avoir une hierarchie a peu pres correcte en dessous de /usr/local.
Accessoirement, c'est pas vraiment une super-idee de gerer ca dans le configure/make/make install d'un logiciel.
- si on veut tester l'existence du repertoire et le creer sinon, ca prend quand meme un certain temps (multiplier ca par 3 millions de creation de repertoire).
- on le cree avec quoi ? toutes les chances de se vautrer si on fait passer un install -d en force (style, pas les bons droits, ou pas le bon proprietaire sur la machine). Un peu naif de le faire avec mkdir -p. et comme dit precedemment, sinon faut se taper un test a la con.
Perso, je prefere largement les applis qui ne touchent pas a ma hierarchie de repertoires, du tout. Meme si ca m'oblige a en creer quelques-uns.
Et j'ai une confiance limitee dans les usines a gaz... d'ailleurs, je me debats avec un cretin de libtool qui ne sait pas reordonner ses options de link correctement et me fout les mauvais -L au bon endroit (ou le contraire).
In article <32o66gF3pakbcU1@individual.net>,
Fabrice <f.bruelpasdepub@wanadoo.fr> wrote:
Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en
théorie pas à des années lumières de Free...
Si je ne me gourre pas, altq est un projet independant, il me semble
que son/ses auteur(s) sont affilies avec kame.
D'ailleurs, nous on a une spec pour mtree pour /usr/local, et on ne
laisse jamais rien se compiler sans remplir /usr/local.
S'attendre a ce que tout marche avec un /usr/local vide releve de la
gageure. J'ai du mal a croire que FreeBSD n'ait pas un equivalent quelque
part et qu'il ne fasse pas avoir une hierarchie a peu pres correcte
en dessous de /usr/local.
Accessoirement, c'est pas vraiment une super-idee de gerer ca dans
le configure/make/make install d'un logiciel.
- si on veut tester l'existence du repertoire et le creer sinon, ca
prend quand meme un certain temps (multiplier ca par 3 millions de
creation de repertoire).
- on le cree avec quoi ? toutes les chances de se vautrer si on fait
passer un install -d en force (style, pas les bons droits, ou pas le
bon proprietaire sur la machine). Un peu naif de le faire avec mkdir -p.
et comme dit precedemment, sinon faut se taper un test a la con.
Perso, je prefere largement les applis qui ne touchent pas a ma hierarchie
de repertoires, du tout. Meme si ca m'oblige a en creer quelques-uns.
Et j'ai une confiance limitee dans les usines a gaz... d'ailleurs, je
me debats avec un cretin de libtool qui ne sait pas reordonner ses options
de link correctement et me fout les mauvais -L au bon endroit (ou le
contraire).
Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en théorie pas à des années lumières de Free...
Si je ne me gourre pas, altq est un projet independant, il me semble que son/ses auteur(s) sont affilies avec kame.
D'ailleurs, nous on a une spec pour mtree pour /usr/local, et on ne laisse jamais rien se compiler sans remplir /usr/local.
S'attendre a ce que tout marche avec un /usr/local vide releve de la gageure. J'ai du mal a croire que FreeBSD n'ait pas un equivalent quelque part et qu'il ne fasse pas avoir une hierarchie a peu pres correcte en dessous de /usr/local.
Accessoirement, c'est pas vraiment une super-idee de gerer ca dans le configure/make/make install d'un logiciel.
- si on veut tester l'existence du repertoire et le creer sinon, ca prend quand meme un certain temps (multiplier ca par 3 millions de creation de repertoire).
- on le cree avec quoi ? toutes les chances de se vautrer si on fait passer un install -d en force (style, pas les bons droits, ou pas le bon proprietaire sur la machine). Un peu naif de le faire avec mkdir -p. et comme dit precedemment, sinon faut se taper un test a la con.
Perso, je prefere largement les applis qui ne touchent pas a ma hierarchie de repertoires, du tout. Meme si ca m'oblige a en creer quelques-uns.
Et j'ai une confiance limitee dans les usines a gaz... d'ailleurs, je me debats avec un cretin de libtool qui ne sait pas reordonner ses options de link correctement et me fout les mauvais -L au bon endroit (ou le contraire).
Fabrice
In article , Fabrice wrote:
Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en théorie pas à des années lumières de Free...
Si je ne me gourre pas, altq est un projet independant, il me semble que son/ses auteur(s) sont affilies avec kame.
D'ailleurs, nous on a une spec pour mtree pour /usr/local, et on ne laisse jamais rien se compiler sans remplir /usr/local.
S'attendre a ce que tout marche avec un /usr/local vide releve de la gageure. J'ai du mal a croire que FreeBSD n'ait pas un equivalent quelque part et qu'il ne fasse pas avoir une hierarchie a peu pres correcte en dessous de /usr/local. Ben en faisant une install standard, en choisissant "kernel developper",
on se retrouve avec un beau /usr/local tout vide...
Je ne m'en étais pas rendu compte avant car j'installais des ports qui devaient du coup créer une arborescence propre.
Pour ALTQ, je l'installe avant tout autre chose et c'est là que le souci m'est apparu.
Perso, je prefere largement les applis qui ne touchent pas a ma hierarchie de repertoires, du tout. Meme si ca m'oblige a en creer quelques-uns. Je préferai que l'install se banane en précisant les répertoires qui lui
manquent, plutôt que de créer un fichier la première fois que l'install y fait référence, ca serait moins le bordel. Dans le cas de ALTQ, il crée un fichier de ce style (je crois bien que c'est /usr/local/bin) du coup ensuite tous les pkg_add se plantaient avec un zoli cannot unlink to ... Avant de se rendre compte que /usr/local/bin était un fichier et non un répertoire et que je le devais au make install d'ALTQ, j'ai cherché un certain temps ...
FAbrice
In article <32o66gF3pakbcU1@individual.net>,
Fabrice <f.bruelpasdepub@wanadoo.fr> wrote:
Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en
théorie pas à des années lumières de Free...
Si je ne me gourre pas, altq est un projet independant, il me semble
que son/ses auteur(s) sont affilies avec kame.
D'ailleurs, nous on a une spec pour mtree pour /usr/local, et on ne
laisse jamais rien se compiler sans remplir /usr/local.
S'attendre a ce que tout marche avec un /usr/local vide releve de la
gageure. J'ai du mal a croire que FreeBSD n'ait pas un equivalent quelque
part et qu'il ne fasse pas avoir une hierarchie a peu pres correcte
en dessous de /usr/local.
Ben en faisant une install standard, en choisissant "kernel developper",
on se retrouve avec un beau /usr/local tout vide...
Je ne m'en étais pas rendu compte avant car j'installais des ports qui
devaient du coup créer une arborescence propre.
Pour ALTQ, je l'installe avant tout autre chose et c'est là que le souci
m'est apparu.
Perso, je prefere largement les applis qui ne touchent pas a ma hierarchie
de repertoires, du tout. Meme si ca m'oblige a en creer quelques-uns.
Je préferai que l'install se banane en précisant les répertoires qui lui
manquent, plutôt que de créer un fichier la première fois que l'install
y fait référence, ca serait moins le bordel. Dans le cas de ALTQ, il
crée un fichier de ce style (je crois bien que c'est /usr/local/bin) du
coup ensuite tous les pkg_add se plantaient avec un zoli cannot unlink
to ... Avant de se rendre compte que /usr/local/bin était un fichier et
non un répertoire et que je le devais au make install d'ALTQ, j'ai
cherché un certain temps ...
Sauf que, si je ne gourre pas, ALTQ est à la base un projet Open donc en théorie pas à des années lumières de Free...
Si je ne me gourre pas, altq est un projet independant, il me semble que son/ses auteur(s) sont affilies avec kame.
D'ailleurs, nous on a une spec pour mtree pour /usr/local, et on ne laisse jamais rien se compiler sans remplir /usr/local.
S'attendre a ce que tout marche avec un /usr/local vide releve de la gageure. J'ai du mal a croire que FreeBSD n'ait pas un equivalent quelque part et qu'il ne fasse pas avoir une hierarchie a peu pres correcte en dessous de /usr/local. Ben en faisant une install standard, en choisissant "kernel developper",
on se retrouve avec un beau /usr/local tout vide...
Je ne m'en étais pas rendu compte avant car j'installais des ports qui devaient du coup créer une arborescence propre.
Pour ALTQ, je l'installe avant tout autre chose et c'est là que le souci m'est apparu.
Perso, je prefere largement les applis qui ne touchent pas a ma hierarchie de repertoires, du tout. Meme si ca m'oblige a en creer quelques-uns. Je préferai que l'install se banane en précisant les répertoires qui lui
manquent, plutôt que de créer un fichier la première fois que l'install y fait référence, ca serait moins le bordel. Dans le cas de ALTQ, il crée un fichier de ce style (je crois bien que c'est /usr/local/bin) du coup ensuite tous les pkg_add se plantaient avec un zoli cannot unlink to ... Avant de se rendre compte que /usr/local/bin était un fichier et non un répertoire et que je le devais au make install d'ALTQ, j'ai cherché un certain temps ...
FAbrice
espie
In article , Fabrice wrote:
Je préferai que l'install se banane en précisant les répertoires qui lui manquent, plutôt que de créer un fichier la première fois que l'install y fait référence, ca serait moins le bordel. Dans le cas de ALTQ, il crée un fichier de ce style (je crois bien que c'est /usr/local/bin) du coup ensuite tous les pkg_add se plantaient avec un zoli cannot unlink to ... Avant de se rendre compte que /usr/local/bin était un fichier et non un répertoire et que je le devais au make install d'ALTQ, j'ai cherché un certain temps ...
Entierement d'accord avec toi.
Le plus simple, c'est sans doute de preciser le nom complet d'installation et ne pas se limiter au repertoire dans la commande install.
Tiens, je vais aller voir de ce pas si automake fait ce qu'il faut. Sinon, ca fait un mignon bug-report, ca.
In article <32sofgF3mnn2nU1@individual.net>,
Fabrice <f.bruelpasdepub@wanadoo.fr> wrote:
Je préferai que l'install se banane en précisant les répertoires qui lui
manquent, plutôt que de créer un fichier la première fois que l'install
y fait référence, ca serait moins le bordel. Dans le cas de ALTQ, il
crée un fichier de ce style (je crois bien que c'est /usr/local/bin) du
coup ensuite tous les pkg_add se plantaient avec un zoli cannot unlink
to ... Avant de se rendre compte que /usr/local/bin était un fichier et
non un répertoire et que je le devais au make install d'ALTQ, j'ai
cherché un certain temps ...
Entierement d'accord avec toi.
Le plus simple, c'est sans doute de preciser le nom complet d'installation
et ne pas se limiter au repertoire dans la commande install.
Tiens, je vais aller voir de ce pas si automake fait ce qu'il faut.
Sinon, ca fait un mignon bug-report, ca.
Je préferai que l'install se banane en précisant les répertoires qui lui manquent, plutôt que de créer un fichier la première fois que l'install y fait référence, ca serait moins le bordel. Dans le cas de ALTQ, il crée un fichier de ce style (je crois bien que c'est /usr/local/bin) du coup ensuite tous les pkg_add se plantaient avec un zoli cannot unlink to ... Avant de se rendre compte que /usr/local/bin était un fichier et non un répertoire et que je le devais au make install d'ALTQ, j'ai cherché un certain temps ...
Entierement d'accord avec toi.
Le plus simple, c'est sans doute de preciser le nom complet d'installation et ne pas se limiter au repertoire dans la commande install.
Tiens, je vais aller voir de ce pas si automake fait ce qu'il faut. Sinon, ca fait un mignon bug-report, ca.
