Quand je compile un Makefile avec l'option -j de make (pour lancer
plusieurs tâches en même temps), cela se passe bien, sauf pour les
archives créées avec ar. En effet "ar" n'est pas réentrant et cela
ce passe mal en général avec un message du genre :
ar: lib.a: Resource temporarily unavailable
Quand je compile un Makefile avec l'option -j de make (pour lancer
plusieurs tâches en même temps), cela se passe bien, sauf pour les
archives créées avec ar. En effet "ar" n'est pas réentrant et cela
ce passe mal en général avec un message du genre :
ar: lib.a: Resource temporarily unavailable
Quand je compile un Makefile avec l'option -j de make (pour lancer
plusieurs tâches en même temps), cela se passe bien, sauf pour les
archives créées avec ar. En effet "ar" n'est pas réentrant et cela
ce passe mal en général avec un message du genre :
ar: lib.a: Resource temporarily unavailable
Dans l'article <C3F4CE18.C6E6B%,
Eric Levenez écrit:Quand je compile un Makefile avec l'option -j de make (pour lancer
plusieurs tâches en même temps), cela se passe bien, sauf pour les
archives créées avec ar. En effet "ar" n'est pas réentrant et cela
ce passe mal en général avec un message du genre :
ar: lib.a: Resource temporarily unavailable
ar n'a pas besoin d'être réentrant. AMHA, c'est simplement un bug
dans les dépendances du Makefile. Pour info, je fais souvent des
compilations avec "make -j2" sous Mac OS X, et je n'ai jamais eu
de problème avec ar (j'ai eu des erreurs avec d'autres choses, mais
il s'agissait de problème de dépendances, qui ont été corrigés).
Un exemple de problème qui peut se poser: lorsqu'une règle génère
plusieurs fichiers (dont certains ne sont donc pas en target), si
bien qu'une dépendance peut être satisfaite avant que l'exécution
de la règle se soit terminée. Il faut donc faire particulièrement
attention à ça en écrivant ses Makefile...
Dans l'article <C3F4CE18.C6E6B%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Quand je compile un Makefile avec l'option -j de make (pour lancer
plusieurs tâches en même temps), cela se passe bien, sauf pour les
archives créées avec ar. En effet "ar" n'est pas réentrant et cela
ce passe mal en général avec un message du genre :
ar: lib.a: Resource temporarily unavailable
ar n'a pas besoin d'être réentrant. AMHA, c'est simplement un bug
dans les dépendances du Makefile. Pour info, je fais souvent des
compilations avec "make -j2" sous Mac OS X, et je n'ai jamais eu
de problème avec ar (j'ai eu des erreurs avec d'autres choses, mais
il s'agissait de problème de dépendances, qui ont été corrigés).
Un exemple de problème qui peut se poser: lorsqu'une règle génère
plusieurs fichiers (dont certains ne sont donc pas en target), si
bien qu'une dépendance peut être satisfaite avant que l'exécution
de la règle se soit terminée. Il faut donc faire particulièrement
attention à ça en écrivant ses Makefile...
Dans l'article <C3F4CE18.C6E6B%,
Eric Levenez écrit:Quand je compile un Makefile avec l'option -j de make (pour lancer
plusieurs tâches en même temps), cela se passe bien, sauf pour les
archives créées avec ar. En effet "ar" n'est pas réentrant et cela
ce passe mal en général avec un message du genre :
ar: lib.a: Resource temporarily unavailable
ar n'a pas besoin d'être réentrant. AMHA, c'est simplement un bug
dans les dépendances du Makefile. Pour info, je fais souvent des
compilations avec "make -j2" sous Mac OS X, et je n'ai jamais eu
de problème avec ar (j'ai eu des erreurs avec d'autres choses, mais
il s'agissait de problème de dépendances, qui ont été corrigés).
Un exemple de problème qui peut se poser: lorsqu'une règle génère
plusieurs fichiers (dont certains ne sont donc pas en target), si
bien qu'une dépendance peut être satisfaite avant que l'exécution
de la règle se soit terminée. Il faut donc faire particulièrement
attention à ça en écrivant ses Makefile...
Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar" plusieurs
fois simultanément sur cette même bibliothèque : le premier "ar" passe", les
autres non. Le traitement dans "ar" est très rapide, et donc la fenêtre où
les problèmes peuvent survenir est faible, mais elle est là. Je vais quand
même revérifier mon Makefile.
Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar" plusieurs
fois simultanément sur cette même bibliothèque : le premier "ar" passe", les
autres non. Le traitement dans "ar" est très rapide, et donc la fenêtre où
les problèmes peuvent survenir est faible, mais elle est là. Je vais quand
même revérifier mon Makefile.
Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar" plusieurs
fois simultanément sur cette même bibliothèque : le premier "ar" passe", les
autres non. Le traitement dans "ar" est très rapide, et donc la fenêtre où
les problèmes peuvent survenir est faible, mais elle est là. Je vais quand
même revérifier mon Makefile.
À (at) Thu, 06 Mar 2008 07:39:01 +0100,
Eric Levenez écrivait (wrote):Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar" plusieurs
fois simultanément sur cette même bibliothèque : le premier "ar" passe", les
autres non. Le traitement dans "ar" est très rapide, et donc la fenêtre où
les problèmes peuvent survenir est faible, mais elle est là. Je vais quand
même revérifier mon Makefile.
C'est que le Makefile n'est pas écrit pour être effectué en tâches
parallèles... Pour bien faire, il faut que la règle de dépendance de
création de la bibliothèque intègre l'ensemble des fichiers membres
nécessaires et que la bibliothèque soit construite en une seule
commande.
À (at) Thu, 06 Mar 2008 07:39:01 +0100,
Eric Levenez <usenet@levenez.com> écrivait (wrote):
Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar" plusieurs
fois simultanément sur cette même bibliothèque : le premier "ar" passe", les
autres non. Le traitement dans "ar" est très rapide, et donc la fenêtre où
les problèmes peuvent survenir est faible, mais elle est là. Je vais quand
même revérifier mon Makefile.
C'est que le Makefile n'est pas écrit pour être effectué en tâches
parallèles... Pour bien faire, il faut que la règle de dépendance de
création de la bibliothèque intègre l'ensemble des fichiers membres
nécessaires et que la bibliothèque soit construite en une seule
commande.
À (at) Thu, 06 Mar 2008 07:39:01 +0100,
Eric Levenez écrivait (wrote):Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar" plusieurs
fois simultanément sur cette même bibliothèque : le premier "ar" passe", les
autres non. Le traitement dans "ar" est très rapide, et donc la fenêtre où
les problèmes peuvent survenir est faible, mais elle est là. Je vais quand
même revérifier mon Makefile.
C'est que le Makefile n'est pas écrit pour être effectué en tâches
parallèles... Pour bien faire, il faut que la règle de dépendance de
création de la bibliothèque intègre l'ensemble des fichiers membres
nécessaires et que la bibliothèque soit construite en une seule
commande.
Avec "make -j2" cela se passe généralement bien, pas avec "make -j"
qui est beaucoup plus violent (surtout avec une machine rapide et
multi-c¦ur).
Un exemple de problème qui peut se poser: lorsqu'une règle génère
plusieurs fichiers (dont certains ne sont donc pas en target), si
bien qu'une dépendance peut être satisfaite avant que l'exécution
de la règle se soit terminée. Il faut donc faire particulièrement
attention à ça en écrivant ses Makefile...
Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar"
plusieurs fois simultanément sur cette même bibliothèque : le
premier "ar" passe", les autres non.
Avec "make -j2" cela se passe généralement bien, pas avec "make -j"
qui est beaucoup plus violent (surtout avec une machine rapide et
multi-c¦ur).
Un exemple de problème qui peut se poser: lorsqu'une règle génère
plusieurs fichiers (dont certains ne sont donc pas en target), si
bien qu'une dépendance peut être satisfaite avant que l'exécution
de la règle se soit terminée. Il faut donc faire particulièrement
attention à ça en écrivant ses Makefile...
Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar"
plusieurs fois simultanément sur cette même bibliothèque : le
premier "ar" passe", les autres non.
Avec "make -j2" cela se passe généralement bien, pas avec "make -j"
qui est beaucoup plus violent (surtout avec une machine rapide et
multi-c¦ur).
Un exemple de problème qui peut se poser: lorsqu'une règle génère
plusieurs fichiers (dont certains ne sont donc pas en target), si
bien qu'une dépendance peut être satisfaite avant que l'exécution
de la règle se soit terminée. Il faut donc faire particulièrement
attention à ça en écrivant ses Makefile...
Oui, cela peut venir de mon Makefile, mais je ne crois pas. J'ai une
bibliothèque avec plein de fichiers dedans et make appelle "ar"
plusieurs fois simultanément sur cette même bibliothèque : le
premier "ar" passe", les autres non.
_ Si ar fait des écritures sur cette bibliothèque, alors évidemment,
c'est un bug de ton Makefile: les dépendances doivent être mises en
place de manière à ne pas avoir deux écritures simultanées sur un
même fichier. C'est une règle de base!
_ Si ar fait des écritures sur cette bibliothèque, alors évidemment,
c'est un bug de ton Makefile: les dépendances doivent être mises en
place de manière à ne pas avoir deux écritures simultanées sur un
même fichier. C'est une règle de base!
_ Si ar fait des écritures sur cette bibliothèque, alors évidemment,
c'est un bug de ton Makefile: les dépendances doivent être mises en
place de manière à ne pas avoir deux écritures simultanées sur un
même fichier. C'est une règle de base!
Le 06/03/08 18:20, dans <20080306171647$, « Vincent
Lefevre » <vincent+ a écrit :_ Si ar fait des écritures sur cette bibliothèque, alors évidemment,
c'est un bug de ton Makefile: les dépendances doivent être mises en
place de manière à ne pas avoir deux écritures simultanées sur un
même fichier. C'est une règle de base!
Oui, mais non. La commande "ar" pourrait très bien gérer les accès
multiples par des verrous
ou il pourrait y avoir une commande ou une option dans le
Makefile pour gérer cela.
Le 06/03/08 18:20, dans <20080306171647$230d@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
_ Si ar fait des écritures sur cette bibliothèque, alors évidemment,
c'est un bug de ton Makefile: les dépendances doivent être mises en
place de manière à ne pas avoir deux écritures simultanées sur un
même fichier. C'est une règle de base!
Oui, mais non. La commande "ar" pourrait très bien gérer les accès
multiples par des verrous
ou il pourrait y avoir une commande ou une option dans le
Makefile pour gérer cela.
Le 06/03/08 18:20, dans <20080306171647$, « Vincent
Lefevre » <vincent+ a écrit :_ Si ar fait des écritures sur cette bibliothèque, alors évidemment,
c'est un bug de ton Makefile: les dépendances doivent être mises en
place de manière à ne pas avoir deux écritures simultanées sur un
même fichier. C'est une règle de base!
Oui, mais non. La commande "ar" pourrait très bien gérer les accès
multiples par des verrous
ou il pourrait y avoir une commande ou une option dans le
Makefile pour gérer cela.
Et maintenant le "make" est plus de 4 fois plus rapide que le "make all" :-)
Et maintenant le "make" est plus de 4 fois plus rapide que le "make all" :-)
Et maintenant le "make" est plus de 4 fois plus rapide que le "make all" :-)
À (at) Thu, 06 Mar 2008 19:56:58 +0100,
Eric Levenez écrivait (wrote):
Et maintenant le "make" est plus de 4 fois plus rapide que le "make all" :-)
Ce qui est sympa, c'est de constater que même sur une machine
mono-processeur, plusieurs compilations en parallèle vont plus vite
que séquentiellement. En fait un compilateur passe une bonne partie de
son temps à accéder au disque (le reste étant la compilation
elle-même). Or compilation et accès disque peuvent se faire en
parallèle même avec un seul processeur.
À (at) Thu, 06 Mar 2008 19:56:58 +0100,
Eric Levenez <usenet@levenez.com> écrivait (wrote):
Et maintenant le "make" est plus de 4 fois plus rapide que le "make all" :-)
Ce qui est sympa, c'est de constater que même sur une machine
mono-processeur, plusieurs compilations en parallèle vont plus vite
que séquentiellement. En fait un compilateur passe une bonne partie de
son temps à accéder au disque (le reste étant la compilation
elle-même). Or compilation et accès disque peuvent se faire en
parallèle même avec un seul processeur.
À (at) Thu, 06 Mar 2008 19:56:58 +0100,
Eric Levenez écrivait (wrote):
Et maintenant le "make" est plus de 4 fois plus rapide que le "make all" :-)
Ce qui est sympa, c'est de constater que même sur une machine
mono-processeur, plusieurs compilations en parallèle vont plus vite
que séquentiellement. En fait un compilateur passe une bonne partie de
son temps à accéder au disque (le reste étant la compilation
elle-même). Or compilation et accès disque peuvent se faire en
parallèle même avec un seul processeur.
Mais il faut voir qu'avec "make -j4" cela lance 4 compilations à la fois,
mais avec une machine 4 c¦urs, cela n'est pas forcément le meilleur choix
car comme tu le dis cela dépend aussi des accès disque. Parfois, c'est "-j3"
par exemple qui est mieux. L'option "-j" seule, qui lance tout en parallèle,
"écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.
Mais il faut voir qu'avec "make -j4" cela lance 4 compilations à la fois,
mais avec une machine 4 c¦urs, cela n'est pas forcément le meilleur choix
car comme tu le dis cela dépend aussi des accès disque. Parfois, c'est "-j3"
par exemple qui est mieux. L'option "-j" seule, qui lance tout en parallèle,
"écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.
Mais il faut voir qu'avec "make -j4" cela lance 4 compilations à la fois,
mais avec une machine 4 c¦urs, cela n'est pas forcément le meilleur choix
car comme tu le dis cela dépend aussi des accès disque. Parfois, c'est "-j3"
par exemple qui est mieux. L'option "-j" seule, qui lance tout en parallèle,
"écroule" la machine quand on a une bibliothèque avec beaucoup de fichiers.