Bonjour à tous,
Et désolé de m'emporter ainsi contre moi-même devant tant de beau
monde !
J'avais donc un problème avec logrotate :
reading config file /etc/logrotate.conf
reading config info for /var/log/messages
Handling 1 logs
rotating pattern: /var/log
messages 104857600 bytes (5 rotations)
empty log files are not rotated, old logs are removed
considering log @
stat of @ failed: No such file or directory
Après avoir fait vérifier par tous ma bonne configuration, monté la
version (en 3.6.8), j'obtiends toujours la même chose.
Puis gerard patel me glisse un début de réponse- la lecture des fichiers de journal à compacter se fait dans
le fichier config.c, routine readConfigFile; cette routine
d'environ 600 lignes de C avec des while, if, imbriqués a
gogo est un exemple de code susceptible de donner des
résultats semi-aléatoires lors de toute variation imprévue
des entrées. Il est envisageable qu'une erreur plus ou moins
énorme de configuration se répercute dans cette construction
d'une manière imprévisible.
qu'il détaille dans un autre post.
Et paf ! Je part en vacances (personne n'est parfais et je m'en
excuse), pensant appliquer cette solution à mon retour.
Et bien sûr (application directe des lois de Murphy), Knode à
"nettoyé" ma base, et le serveur de news aussi. Donc plus de
solution :`-(
J'ai bien essayé de trouver par moi-même (on a sa fierté quand
même ;-) mais le config.c est un brin confus pour moi (les pointeurs
de pointeurs, j'ai jamais réussi à suivre).
Une âme bien intentionnée pourrait-elle me souffler la réponse ?
Merci,
Bonjour à tous,
Et désolé de m'emporter ainsi contre moi-même devant tant de beau
monde !
J'avais donc un problème avec logrotate :
reading config file /etc/logrotate.conf
reading config info for /var/log/messages
Handling 1 logs
rotating pattern: /var/log
messages 104857600 bytes (5 rotations)
empty log files are not rotated, old logs are removed
considering log pW@h@
stat of pW@h@ failed: No such file or directory
Après avoir fait vérifier par tous ma bonne configuration, monté la
version (en 3.6.8), j'obtiends toujours la même chose.
Puis gerard patel me glisse un début de réponse
- la lecture des fichiers de journal à compacter se fait dans
le fichier config.c, routine readConfigFile; cette routine
d'environ 600 lignes de C avec des while, if, imbriqués a
gogo est un exemple de code susceptible de donner des
résultats semi-aléatoires lors de toute variation imprévue
des entrées. Il est envisageable qu'une erreur plus ou moins
énorme de configuration se répercute dans cette construction
d'une manière imprévisible.
qu'il détaille dans un autre post.
Et paf ! Je part en vacances (personne n'est parfais et je m'en
excuse), pensant appliquer cette solution à mon retour.
Et bien sûr (application directe des lois de Murphy), Knode à
"nettoyé" ma base, et le serveur de news aussi. Donc plus de
solution :`-(
J'ai bien essayé de trouver par moi-même (on a sa fierté quand
même ;-) mais le config.c est un brin confus pour moi (les pointeurs
de pointeurs, j'ai jamais réussi à suivre).
Une âme bien intentionnée pourrait-elle me souffler la réponse ?
Merci,
Bonjour à tous,
Et désolé de m'emporter ainsi contre moi-même devant tant de beau
monde !
J'avais donc un problème avec logrotate :
reading config file /etc/logrotate.conf
reading config info for /var/log/messages
Handling 1 logs
rotating pattern: /var/log
messages 104857600 bytes (5 rotations)
empty log files are not rotated, old logs are removed
considering log @
stat of @ failed: No such file or directory
Après avoir fait vérifier par tous ma bonne configuration, monté la
version (en 3.6.8), j'obtiends toujours la même chose.
Puis gerard patel me glisse un début de réponse- la lecture des fichiers de journal à compacter se fait dans
le fichier config.c, routine readConfigFile; cette routine
d'environ 600 lignes de C avec des while, if, imbriqués a
gogo est un exemple de code susceptible de donner des
résultats semi-aléatoires lors de toute variation imprévue
des entrées. Il est envisageable qu'une erreur plus ou moins
énorme de configuration se répercute dans cette construction
d'une manière imprévisible.
qu'il détaille dans un autre post.
Et paf ! Je part en vacances (personne n'est parfais et je m'en
excuse), pensant appliquer cette solution à mon retour.
Et bien sûr (application directe des lois de Murphy), Knode à
"nettoyé" ma base, et le serveur de news aussi. Donc plus de
solution :`-(
J'ai bien essayé de trouver par moi-même (on a sa fierté quand
même ;-) mais le config.c est un brin confus pour moi (les pointeurs
de pointeurs, j'ai jamais réussi à suivre).
Une âme bien intentionnée pourrait-elle me souffler la réponse ?
Merci,
Pas sûr d'avoir compris votre question.
Si, ci, vous avez parfaitement compris.
Vous cherchez le post de Gérard PATEL dans lequel il vous soufflait
un bout de code à modifier ? Si c'est bien ça, ce post est toujours
présent sur votre serveur de news et il est ici :
<news:
Alors, ça, j'aimerais bien savoir comment on fait pour retrouver un
Ou bien sûr dans les archives de Google :
http://groups.google.fr/groups?
40news.hrnet.fr
Merci,
De rien en espérant avoir répondu à la bonne question.
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur une
autre machine ou d'un paquet d'une quelconque distribution et de
tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Pas sûr d'avoir compris votre question.
Si, ci, vous avez parfaitement compris.
Vous cherchez le post de Gérard PATEL dans lequel il vous soufflait
un bout de code à modifier ? Si c'est bien ça, ce post est toujours
présent sur votre serveur de news et il est ici :
<news:407c41de.48332475@news.hrnet.fr>
Alors, ça, j'aimerais bien savoir comment on fait pour retrouver un
Ou bien sûr dans les archives de Google :
http://groups.google.fr/groups?selm@7c41de.48332475
40news.hrnet.fr
Merci,
De rien en espérant avoir répondu à la bonne question.
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur une
autre machine ou d'un paquet d'une quelconque distribution et de
tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Pas sûr d'avoir compris votre question.
Si, ci, vous avez parfaitement compris.
Vous cherchez le post de Gérard PATEL dans lequel il vous soufflait
un bout de code à modifier ? Si c'est bien ça, ce post est toujours
présent sur votre serveur de news et il est ici :
<news:
Alors, ça, j'aimerais bien savoir comment on fait pour retrouver un
Ou bien sûr dans les archives de Google :
http://groups.google.fr/groups?
40news.hrnet.fr
Merci,
De rien en espérant avoir répondu à la bonne question.
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur une
autre machine ou d'un paquet d'une quelconque distribution et de
tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Pas sûr d'avoir compris votre question.
Si, si, vous avez parfaitement compris.
Vous cherchez le post de Gérard PATEL dans lequel il vous soufflait
un bout de code à modifier ? Si c'est bien ça, ce post est toujours
présent sur votre serveur de news et il est ici :
<news:
Alors, ça, j'aimerais bien savoir comment on fait pour retrouver un
Ou bien sûr dans les archives de Google :
http://groups.google.fr/groups?
Je ne connaissais pas le truc. Une recherche sous Google n'avait
Merci,
De rien en espérant avoir répondu à la bonne question.
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur une
autre machine ou d'un paquet d'une quelconque distribution et de
tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Pas sûr d'avoir compris votre question.
Si, si, vous avez parfaitement compris.
Vous cherchez le post de Gérard PATEL dans lequel il vous soufflait
un bout de code à modifier ? Si c'est bien ça, ce post est toujours
présent sur votre serveur de news et il est ici :
<news:407c41de.48332475@news.hrnet.fr>
Alors, ça, j'aimerais bien savoir comment on fait pour retrouver un
Ou bien sûr dans les archives de Google :
http://groups.google.fr/groups?selm@7c41de.4833247540news.hrnet.fr
Je ne connaissais pas le truc. Une recherche sous Google n'avait
Merci,
De rien en espérant avoir répondu à la bonne question.
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur une
autre machine ou d'un paquet d'une quelconque distribution et de
tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Pas sûr d'avoir compris votre question.
Si, si, vous avez parfaitement compris.
Vous cherchez le post de Gérard PATEL dans lequel il vous soufflait
un bout de code à modifier ? Si c'est bien ça, ce post est toujours
présent sur votre serveur de news et il est ici :
<news:
Alors, ça, j'aimerais bien savoir comment on fait pour retrouver un
Ou bien sûr dans les archives de Google :
http://groups.google.fr/groups?
Je ne connaissais pas le truc. Une recherche sous Google n'avait
Merci,
De rien en espérant avoir répondu à la bonne question.
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur une
autre machine ou d'un paquet d'une quelconque distribution et de
tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur
une autre machine ou d'un paquet d'une quelconque distribution et
de tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Bon alors, j'ai essayé, et ça marche (avec la même version de la
dans config.c, il doit se trouver quelque chose comme ça :
newlog->files[newlog->numFiles] > globResult.gl_pathv[i];
newlog->numFiles++;
il faudrait mettre entre ces deux lignes :
message(MESS_DEBUG, "file %d : %sn", newlog->numFiles,
globResult.gl_pathv[i]);
et effectivement, j'obtiens :
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur
une autre machine ou d'un paquet d'une quelconque distribution et
de tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Bon alors, j'ai essayé, et ça marche (avec la même version de la
dans config.c, il doit se trouver quelque chose comme ça :
newlog->files[newlog->numFiles] > globResult.gl_pathv[i];
newlog->numFiles++;
il faudrait mettre entre ces deux lignes :
message(MESS_DEBUG, "file %d : %sn", newlog->numFiles,
globResult.gl_pathv[i]);
et effectivement, j'obtiens :
Sinon, j'avais suivi de prêt votre problème sans être intervenu et
après avoir étudié le fonctionnement de logrotate en analysant les
sources et le strace sur différentes machines, je penche quand même
fortement pour un problème de librairie buggée, à priori sur la
fonction 'lstat' ou bien le passage des paramètres sur celle ci.
Avez-vous essayé d'utiliser le binaire obtenu sur une autre machine
avec une glibc équivalente ? Ou bien de récupérer le binaire sur
une autre machine ou d'un paquet d'une quelconque distribution et
de tester si celui-ci fonctionne sur votre système ?
Effectivement, je vais essayer.
Bon alors, j'ai essayé, et ça marche (avec la même version de la
dans config.c, il doit se trouver quelque chose comme ça :
newlog->files[newlog->numFiles] > globResult.gl_pathv[i];
newlog->numFiles++;
il faudrait mettre entre ces deux lignes :
message(MESS_DEBUG, "file %d : %sn", newlog->numFiles,
globResult.gl_pathv[i]);
et effectivement, j'obtiens :
Ne voulant pas laisser mon système faire des trucs que je ne comprends
pas, j'ai appliqué la méthode de gerard patel :dans config.c, il doit se trouver quelque chose comme ça :
newlog->files[newlog->numFiles] >> globResult.gl_pathv[i];
newlog->numFiles++;
il faudrait mettre entre ces deux lignes :
message(MESS_DEBUG, "file %d : %sn", newlog->numFiles,
globResult.gl_pathv[i]);
et effectivement, j'obtiens :
reading config file /etc/logrotate.conf
file 0 : @
reading config info for /var/log/messages
error: /etc/logrotate.conf:19 duplicate log entry for @
Je regarde donc plus précisement le code et je me rends compte que
globResult est calculé quelques lignes plus haut avec lstat.
Je me suis donc lancé dans /usr/include pour trouver ce que faisait le
code de lstat et je ne l'ai pas trouvé :-(
Par contre, en appliquant un find /usr/include -exec grep -l lstat, je
trouve un fichier /usr/include/glob.h qui n'apparaît pas dans le
usr/include de l'autre machine (sur laquelle j'ai réussi à compiler
un logrotate qui fonctionne).
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier glob.h
de la glibc par un autre ! Et il se trouve que Kerberos5 (Heimdal)
est présent sur ma machine et pas sur celle qui "fonctione
bien" (j'entends au sens de la compilation de logrotate).
D'où mes interrogations :
Si Kerberos5 remplace le glob.h de la glibc, pourquoi n'en n'ais-je
pas sur la machine où il n'y a pas de Kerberos5 ?
Faut-il que je réinstalle la glibc (avec exactement les mêmes options
que lors de son installation) pour retrouver un glob.h qui tourne ?
Ne voulant pas laisser mon système faire des trucs que je ne comprends
pas, j'ai appliqué la méthode de gerard patel :
dans config.c, il doit se trouver quelque chose comme ça :
newlog->files[newlog->numFiles] >> globResult.gl_pathv[i];
newlog->numFiles++;
il faudrait mettre entre ces deux lignes :
message(MESS_DEBUG, "file %d : %sn", newlog->numFiles,
globResult.gl_pathv[i]);
et effectivement, j'obtiens :
reading config file /etc/logrotate.conf
file 0 : pW@h@
reading config info for /var/log/messages
error: /etc/logrotate.conf:19 duplicate log entry for pW@h@
Je regarde donc plus précisement le code et je me rends compte que
globResult est calculé quelques lignes plus haut avec lstat.
Je me suis donc lancé dans /usr/include pour trouver ce que faisait le
code de lstat et je ne l'ai pas trouvé :-(
Par contre, en appliquant un find /usr/include -exec grep -l lstat, je
trouve un fichier /usr/include/glob.h qui n'apparaît pas dans le
usr/include de l'autre machine (sur laquelle j'ai réussi à compiler
un logrotate qui fonctionne).
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier glob.h
de la glibc par un autre ! Et il se trouve que Kerberos5 (Heimdal)
est présent sur ma machine et pas sur celle qui "fonctione
bien" (j'entends au sens de la compilation de logrotate).
D'où mes interrogations :
Si Kerberos5 remplace le glob.h de la glibc, pourquoi n'en n'ais-je
pas sur la machine où il n'y a pas de Kerberos5 ?
Faut-il que je réinstalle la glibc (avec exactement les mêmes options
que lors de son installation) pour retrouver un glob.h qui tourne ?
Ne voulant pas laisser mon système faire des trucs que je ne comprends
pas, j'ai appliqué la méthode de gerard patel :dans config.c, il doit se trouver quelque chose comme ça :
newlog->files[newlog->numFiles] >> globResult.gl_pathv[i];
newlog->numFiles++;
il faudrait mettre entre ces deux lignes :
message(MESS_DEBUG, "file %d : %sn", newlog->numFiles,
globResult.gl_pathv[i]);
et effectivement, j'obtiens :
reading config file /etc/logrotate.conf
file 0 : @
reading config info for /var/log/messages
error: /etc/logrotate.conf:19 duplicate log entry for @
Je regarde donc plus précisement le code et je me rends compte que
globResult est calculé quelques lignes plus haut avec lstat.
Je me suis donc lancé dans /usr/include pour trouver ce que faisait le
code de lstat et je ne l'ai pas trouvé :-(
Par contre, en appliquant un find /usr/include -exec grep -l lstat, je
trouve un fichier /usr/include/glob.h qui n'apparaît pas dans le
usr/include de l'autre machine (sur laquelle j'ai réussi à compiler
un logrotate qui fonctionne).
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier glob.h
de la glibc par un autre ! Et il se trouve que Kerberos5 (Heimdal)
est présent sur ma machine et pas sur celle qui "fonctione
bien" (j'entends au sens de la compilation de logrotate).
D'où mes interrogations :
Si Kerberos5 remplace le glob.h de la glibc, pourquoi n'en n'ais-je
pas sur la machine où il n'y a pas de Kerberos5 ?
Faut-il que je réinstalle la glibc (avec exactement les mêmes options
que lors de son installation) pour retrouver un glob.h qui tourne ?
Je me suis donc lancé dans /usr/include pour trouver ce que faisait
le code de lstat et je ne l'ai pas trouvé :-(
Normal, c'est un appel système. Pas trop de risque de problèmes de
ce coté là...
Bon, ben de ce côté là, j'aurais appris quelque chose.
Par contre, en appliquant un find /usr/include -exec grep -l lstat,
je trouve un fichier /usr/include/glob.h qui n'apparaît pas dans le
usr/include de l'autre machine (sur laquelle j'ai réussi à compiler
un logrotate qui fonctionne).
locate glob.h ne donne rien ?
Mea culpa, j'ai dû le passer sans le voir, mais il est bien dans /usr
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier
glob.h de la glibc par un autre ! Et il se trouve que Kerberos5
(Heimdal) est présent sur ma machine et pas sur celle qui
"fonctione bien" (j'entends au sens de la compilation de
logrotate).
D'où mes interrogations :
Si Kerberos5 remplace le glob.h de la glibc, pourquoi n'en n'ais-je
pas sur la machine où il n'y a pas de Kerberos5 ?
Tu es bien certain:
man glob donne bien glob.h en référence. Et il est censé être dans
/usr/include. Et il est standard POSIX, donc c'est étrange qu'il
n'existe pas... Et surtout que ça compile sans lui !
Mais si kerberos le remplace, ça explique le problème !
Il doit y avoir une différence entre les headers: la libc supporte
le 64 bits, par ex, et les structures retournées par les versions
32 bits et 64 bits ne sont pas les mêmes... Ca peut causer de
sérieux problèmes !
J'ai comparé les deux fichiers, et ils sont complètement différents !
Faut-il que je réinstalle la glibc (avec exactement les mêmes
options que lors de son installation) pour retrouver un glob.h qui
tourne ?
Ca parait sage...
D'accord, mais alors là, j'ai un peu peur (du temps où j'avais la
Je me suis donc lancé dans /usr/include pour trouver ce que faisait
le code de lstat et je ne l'ai pas trouvé :-(
Normal, c'est un appel système. Pas trop de risque de problèmes de
ce coté là...
Bon, ben de ce côté là, j'aurais appris quelque chose.
Par contre, en appliquant un find /usr/include -exec grep -l lstat,
je trouve un fichier /usr/include/glob.h qui n'apparaît pas dans le
usr/include de l'autre machine (sur laquelle j'ai réussi à compiler
un logrotate qui fonctionne).
locate glob.h ne donne rien ?
Mea culpa, j'ai dû le passer sans le voir, mais il est bien dans /usr
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier
glob.h de la glibc par un autre ! Et il se trouve que Kerberos5
(Heimdal) est présent sur ma machine et pas sur celle qui
"fonctione bien" (j'entends au sens de la compilation de
logrotate).
D'où mes interrogations :
Si Kerberos5 remplace le glob.h de la glibc, pourquoi n'en n'ais-je
pas sur la machine où il n'y a pas de Kerberos5 ?
Tu es bien certain:
man glob donne bien glob.h en référence. Et il est censé être dans
/usr/include. Et il est standard POSIX, donc c'est étrange qu'il
n'existe pas... Et surtout que ça compile sans lui !
Mais si kerberos le remplace, ça explique le problème !
Il doit y avoir une différence entre les headers: la libc supporte
le 64 bits, par ex, et les structures retournées par les versions
32 bits et 64 bits ne sont pas les mêmes... Ca peut causer de
sérieux problèmes !
J'ai comparé les deux fichiers, et ils sont complètement différents !
Faut-il que je réinstalle la glibc (avec exactement les mêmes
options que lors de son installation) pour retrouver un glob.h qui
tourne ?
Ca parait sage...
D'accord, mais alors là, j'ai un peu peur (du temps où j'avais la
Je me suis donc lancé dans /usr/include pour trouver ce que faisait
le code de lstat et je ne l'ai pas trouvé :-(
Normal, c'est un appel système. Pas trop de risque de problèmes de
ce coté là...
Bon, ben de ce côté là, j'aurais appris quelque chose.
Par contre, en appliquant un find /usr/include -exec grep -l lstat,
je trouve un fichier /usr/include/glob.h qui n'apparaît pas dans le
usr/include de l'autre machine (sur laquelle j'ai réussi à compiler
un logrotate qui fonctionne).
locate glob.h ne donne rien ?
Mea culpa, j'ai dû le passer sans le voir, mais il est bien dans /usr
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier
glob.h de la glibc par un autre ! Et il se trouve que Kerberos5
(Heimdal) est présent sur ma machine et pas sur celle qui
"fonctione bien" (j'entends au sens de la compilation de
logrotate).
D'où mes interrogations :
Si Kerberos5 remplace le glob.h de la glibc, pourquoi n'en n'ais-je
pas sur la machine où il n'y a pas de Kerberos5 ?
Tu es bien certain:
man glob donne bien glob.h en référence. Et il est censé être dans
/usr/include. Et il est standard POSIX, donc c'est étrange qu'il
n'existe pas... Et surtout que ça compile sans lui !
Mais si kerberos le remplace, ça explique le problème !
Il doit y avoir une différence entre les headers: la libc supporte
le 64 bits, par ex, et les structures retournées par les versions
32 bits et 64 bits ne sont pas les mêmes... Ca peut causer de
sérieux problèmes !
J'ai comparé les deux fichiers, et ils sont complètement différents !
Faut-il que je réinstalle la glibc (avec exactement les mêmes
options que lors de son installation) pour retrouver un glob.h qui
tourne ?
Ca parait sage...
D'accord, mais alors là, j'ai un peu peur (du temps où j'avais la
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier glob.h
de la glibc par un autre !
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier glob.h
de la glibc par un autre !
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier glob.h
de la glibc par un autre !
On Fri, 30 Apr 2004 20:57:28 +0200, Laurent =?ISO-8859-15?Q?Hugé? > wrote:En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier
glob.h de la glibc par un autre !
hum. Quel est la référence de ce post ?
C'est http://linuxfromscratch.org/pipermail
J'ai téléchargé
kerberos 5 du MIT (adresse :
http://web.mit.edu/kerberos/www/dist/krb5/1.3/krb5-1.3.3.tar5)
et le paquetage ne contient pas plus de glob.h que de
beurre en broche; ça m'étonnait vraiment d'ailleurs :-)
J'ai récupéré Kerberos5 Heimdal (sur http://www.pdc.kth.se/heimdal/).
Puisque le problème vient de la compilation de logrotate,
peut-etre que le config.log contient des éléments intéressants.
Non, parce qu'il n'y a pas de configure dans les sources de logrotate
Et puis un glob.h, ça peut se remplacer provisoirement à
la main, pour voir. Pas la peine de réinstaller la glibc rien
que pour faire un essai (mais quand on fait du LFS, on ne
devrait avoir peur de rien, non ?)
Oulà, ne faisons pas d'amalgame ! Avoir une LFS, c'est se dire ; linux
On Fri, 30 Apr 2004 20:57:28 +0200, Laurent =?ISO-8859-15?Q?Hugé? > <hugePasDeSpam.root@freePasDeSpam.fr> wrote:
En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier
glob.h de la glibc par un autre !
hum. Quel est la référence de ce post ?
C'est http://linuxfromscratch.org/pipermail
J'ai téléchargé
kerberos 5 du MIT (adresse :
http://web.mit.edu/kerberos/www/dist/krb5/1.3/krb5-1.3.3.tar5)
et le paquetage ne contient pas plus de glob.h que de
beurre en broche; ça m'étonnait vraiment d'ailleurs :-)
J'ai récupéré Kerberos5 Heimdal (sur http://www.pdc.kth.se/heimdal/).
Puisque le problème vient de la compilation de logrotate,
peut-etre que le config.log contient des éléments intéressants.
Non, parce qu'il n'y a pas de configure dans les sources de logrotate
Et puis un glob.h, ça peut se remplacer provisoirement à
la main, pour voir. Pas la peine de réinstaller la glibc rien
que pour faire un essai (mais quand on fait du LFS, on ne
devrait avoir peur de rien, non ?)
Oulà, ne faisons pas d'amalgame ! Avoir une LFS, c'est se dire ; linux
On Fri, 30 Apr 2004 20:57:28 +0200, Laurent =?ISO-8859-15?Q?Hugé? > wrote:En faisant une recherche sur Google, je trouve un post sur
linuxfromscratch qui affirme que Kerberos5 remplace le fichier
glob.h de la glibc par un autre !
hum. Quel est la référence de ce post ?
C'est http://linuxfromscratch.org/pipermail
J'ai téléchargé
kerberos 5 du MIT (adresse :
http://web.mit.edu/kerberos/www/dist/krb5/1.3/krb5-1.3.3.tar5)
et le paquetage ne contient pas plus de glob.h que de
beurre en broche; ça m'étonnait vraiment d'ailleurs :-)
J'ai récupéré Kerberos5 Heimdal (sur http://www.pdc.kth.se/heimdal/).
Puisque le problème vient de la compilation de logrotate,
peut-etre que le config.log contient des éléments intéressants.
Non, parce qu'il n'y a pas de configure dans les sources de logrotate
Et puis un glob.h, ça peut se remplacer provisoirement à
la main, pour voir. Pas la peine de réinstaller la glibc rien
que pour faire un essai (mais quand on fait du LFS, on ne
devrait avoir peur de rien, non ?)
Oulà, ne faisons pas d'amalgame ! Avoir une LFS, c'est se dire ; linux
Cela dit, je vais faire le remplacement de glob.h (même pas peur ;-)
Je l'ai fait. Ça marche (ouf ;-). Je considère que c'est bon ? (ou
Cela dit, je vais faire le remplacement de glob.h (même pas peur ;-)
Je l'ai fait. Ça marche (ouf ;-). Je considère que c'est bon ? (ou
Cela dit, je vais faire le remplacement de glob.h (même pas peur ;-)
Je l'ai fait. Ça marche (ouf ;-). Je considère que c'est bon ? (ou
