Le 16-05-2010, ? propos de
Re: [C99] gcc et fonctions 'inline',
Marc Espie ?crivait dans fr.comp.lang.c :Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
Il y a effectivement des problèmes de locales, mais ça se contourne
(assez) facilement. Les problèmes que j'ai sont surtout liés Ã
l'utilisation des threads POSIX sous OpenBSD (avec sigaltstack pour
récupérer les débordements de pile et les signaux) ainsi que la
gestion des signaux par thread.
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)
Pas sur les points qui m'intéressent. Mes bugs reports datent au
moins de la 4.2 sans que ça progresse significativement. Tu me diras
que je n'ai qu'Ã ne pas torturer les specs POSIX comme je le fais et
tu auras sans doute raison. Le problème est que je n'ai pas vraiment
le choix pour avoir quelque chose d'à -peu-près portable sur mes
systèmes d'exploitation et architectures cibles. Le compilo
gcc d'Open est aussi un truc bizarre. Pour avoir le moins de
problème, j'utilise toujours le gcc mainstream officiel, pas celui
de la distribution. Mon code embarque du Fortran 9x, 2003, mais
aussi 77 ainsi que du C89 et maintenant du C99. Il me faut donc un
gcc au moins égal à 4.0 et un gfortran au moins égal à 4.3, et
là , ça devient franchement marrant. La dernière fois que j'ai dû
compiler un 4.3 ou 4.4 sous OpenBSD, ce n'était pas la joie, parce
que le compilo par défaut est un 3.x qui bootstrappe difficilement
un gcc 4.3. Et pourtant, j'ai déjà compilé gcc sur des architectures
largement plus exotique que OpenBSD/x86.
Pour dériver un peu, lorsque je fais un bug report sur un point
précis, l'équipe de NetBSD ou de FreeBSD traite le problème dans un
délai raisonnable (le dernier que j'ai fait chez Free a été traité
en une semaine). La même chose chez Open me revient avec un "won't
fix" ou un magnifique "ne sera pas implanté parce que non 'secure'"
pour le coup des symboles faibles pthread/sigaltstack
Le 16-05-2010, ? propos de
Re: [C99] gcc et fonctions 'inline',
Marc Espie ?crivait dans fr.comp.lang.c :
Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
Il y a effectivement des problèmes de locales, mais ça se contourne
(assez) facilement. Les problèmes que j'ai sont surtout liés Ã
l'utilisation des threads POSIX sous OpenBSD (avec sigaltstack pour
récupérer les débordements de pile et les signaux) ainsi que la
gestion des signaux par thread.
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)
Pas sur les points qui m'intéressent. Mes bugs reports datent au
moins de la 4.2 sans que ça progresse significativement. Tu me diras
que je n'ai qu'Ã ne pas torturer les specs POSIX comme je le fais et
tu auras sans doute raison. Le problème est que je n'ai pas vraiment
le choix pour avoir quelque chose d'à -peu-près portable sur mes
systèmes d'exploitation et architectures cibles. Le compilo
gcc d'Open est aussi un truc bizarre. Pour avoir le moins de
problème, j'utilise toujours le gcc mainstream officiel, pas celui
de la distribution. Mon code embarque du Fortran 9x, 2003, mais
aussi 77 ainsi que du C89 et maintenant du C99. Il me faut donc un
gcc au moins égal à 4.0 et un gfortran au moins égal à 4.3, et
là , ça devient franchement marrant. La dernière fois que j'ai dû
compiler un 4.3 ou 4.4 sous OpenBSD, ce n'était pas la joie, parce
que le compilo par défaut est un 3.x qui bootstrappe difficilement
un gcc 4.3. Et pourtant, j'ai déjà compilé gcc sur des architectures
largement plus exotique que OpenBSD/x86.
Pour dériver un peu, lorsque je fais un bug report sur un point
précis, l'équipe de NetBSD ou de FreeBSD traite le problème dans un
délai raisonnable (le dernier que j'ai fait chez Free a été traité
en une semaine). La même chose chez Open me revient avec un "won't
fix" ou un magnifique "ne sera pas implanté parce que non 'secure'"
pour le coup des symboles faibles pthread/sigaltstack
Le 16-05-2010, ? propos de
Re: [C99] gcc et fonctions 'inline',
Marc Espie ?crivait dans fr.comp.lang.c :Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
Il y a effectivement des problèmes de locales, mais ça se contourne
(assez) facilement. Les problèmes que j'ai sont surtout liés Ã
l'utilisation des threads POSIX sous OpenBSD (avec sigaltstack pour
récupérer les débordements de pile et les signaux) ainsi que la
gestion des signaux par thread.
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)
Pas sur les points qui m'intéressent. Mes bugs reports datent au
moins de la 4.2 sans que ça progresse significativement. Tu me diras
que je n'ai qu'Ã ne pas torturer les specs POSIX comme je le fais et
tu auras sans doute raison. Le problème est que je n'ai pas vraiment
le choix pour avoir quelque chose d'à -peu-près portable sur mes
systèmes d'exploitation et architectures cibles. Le compilo
gcc d'Open est aussi un truc bizarre. Pour avoir le moins de
problème, j'utilise toujours le gcc mainstream officiel, pas celui
de la distribution. Mon code embarque du Fortran 9x, 2003, mais
aussi 77 ainsi que du C89 et maintenant du C99. Il me faut donc un
gcc au moins égal à 4.0 et un gfortran au moins égal à 4.3, et
là , ça devient franchement marrant. La dernière fois que j'ai dû
compiler un 4.3 ou 4.4 sous OpenBSD, ce n'était pas la joie, parce
que le compilo par défaut est un 3.x qui bootstrappe difficilement
un gcc 4.3. Et pourtant, j'ai déjà compilé gcc sur des architectures
largement plus exotique que OpenBSD/x86.
Pour dériver un peu, lorsque je fais un bug report sur un point
précis, l'équipe de NetBSD ou de FreeBSD traite le problème dans un
délai raisonnable (le dernier que j'ai fait chez Free a été traité
en une semaine). La même chose chez Open me revient avec un "won't
fix" ou un magnifique "ne sera pas implanté parce que non 'secure'"
pour le coup des symboles faibles pthread/sigaltstack
In article ,
JKB wrote:Le 16-05-2010, ? propos de
Re: [C99] gcc et fonctions 'inline',
Marc Espie ?crivait dans fr.comp.lang.c :Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
Il y a effectivement des problèmes de locales, mais ça se contourne
(assez) facilement. Les problèmes que j'ai sont surtout liés à
l'utilisation des threads POSIX sous OpenBSD (avec sigaltstack pour
récupérer les débordements de pile et les signaux) ainsi que la
gestion des signaux par thread.
Sur le long terme, on espere bien passer a uthread un jour prochain. Les
soucis que tu vois sont lies a pthread.
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)Pas sur les points qui m'intéressent. Mes bugs reports datent au
moins de la 4.2 sans que ça progresse significativement. Tu me diras
que je n'ai qu'à ne pas torturer les specs POSIX comme je le fais et
tu auras sans doute raison. Le problème est que je n'ai pas vraiment
le choix pour avoir quelque chose d'à-peu-près portable sur mes
systèmes d'exploitation et architectures cibles. Le compilo
gcc d'Open est aussi un truc bizarre. Pour avoir le moins de
problème, j'utilise toujours le gcc mainstream officiel, pas celui
de la distribution. Mon code embarque du Fortran 9x, 2003, mais
aussi 77 ainsi que du C89 et maintenant du C99. Il me faut donc un
gcc au moins égal à 4.0 et un gfortran au moins égal à 4.3, et
là, ça devient franchement marrant. La dernière fois que j'ai dû
compiler un 4.3 ou 4.4 sous OpenBSD, ce n'était pas la joie, parce
que le compilo par défaut est un 3.x qui bootstrappe difficilement
un gcc 4.3. Et pourtant, j'ai déjà compilé gcc sur des architectures
largement plus exotique que OpenBSD/x86.
Je suis bien place pour te repondre, vu que je suis plus ou moins "responsable"
des gcc qui trainent dans l'arbre des ports.
T'es alle voir ce qu'il y avait dans ports/lang/gcc/4.3, au moins au niveau
patch, ou t'es vraiment completement maso et t'as tout fait a la main ?
Oui, le compilo Open est bizarre. C'est entre autres lie au fait que j'ai
depuis un certain temps laisse tomber l'idee d'avoir un jour toutes nos
modifs "upstream". Mark Kettenis s'obstine encore un peu. Mais c'est
tellement dur de passer les modifs dans GCC officiel FSF qu'on a a
moitie renonce !
Note que la plupart de tes soucis de compilation d'un GCC 4.3, on les a eu.
Selon le cas:
- soit c'est une branche trop vieille pour la FSF, et ils refusent les patchs
pour que ca compile out-of-the-box.
- soit ca tourne rapidement au bras de fer avec eux a partir du moment ou on
a des raisons (plus ou moins legitimes, mais passons...) de faire les choses
differemment, et qu'ils ne sont pas d'accord...
Rappel, lie a un de mes messages precedents. Ca me prend generalement dix fois
plus de temps pour arriver a remonter un patch upstream *et a le faire prendre
en compte* sur gcc que pour n'importe quel autre projet auquel je contribue...
Pour dériver un peu, lorsque je fais un bug report sur un point
précis, l'équipe de NetBSD ou de FreeBSD traite le problème dans un
délai raisonnable (le dernier que j'ai fait chez Free a été traité
en une semaine). La même chose chez Open me revient avec un "won't
fix" ou un magnifique "ne sera pas implanté parce que non 'secure'"
pour le coup des symboles faibles pthread/sigaltstack
Il y a plein, plein de problemes connus dans pthreads! La solution, c'est
d'avoir des threads noyaux. Il y a Guenther qui bosse sur rthreads, mais
ca prend du temps... et pour les problemes que tu vois, si c'est trop
complique... ca bouffe du temps qui ne sera pas utilise pour faire avancer
rthreads...
Je ne te donnerai pas de delais, mais c'est un des gros chantiers sur lesquels
on espere bien avoir quelque chose un jour... si d'autres personnes competentes
s'y mettent, ca pourrait avancer plus vite.
In article <slrnhuvmrk.ull.knatschke@rayleigh.systella.fr>,
JKB <wilhelm-siegfried.knatschke-koenigsberg@chezmoi.com> wrote:
Le 16-05-2010, ? propos de
Re: [C99] gcc et fonctions 'inline',
Marc Espie ?crivait dans fr.comp.lang.c :
Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
Il y a effectivement des problèmes de locales, mais ça se contourne
(assez) facilement. Les problèmes que j'ai sont surtout liés à
l'utilisation des threads POSIX sous OpenBSD (avec sigaltstack pour
récupérer les débordements de pile et les signaux) ainsi que la
gestion des signaux par thread.
Sur le long terme, on espere bien passer a uthread un jour prochain. Les
soucis que tu vois sont lies a pthread.
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)
Pas sur les points qui m'intéressent. Mes bugs reports datent au
moins de la 4.2 sans que ça progresse significativement. Tu me diras
que je n'ai qu'à ne pas torturer les specs POSIX comme je le fais et
tu auras sans doute raison. Le problème est que je n'ai pas vraiment
le choix pour avoir quelque chose d'à-peu-près portable sur mes
systèmes d'exploitation et architectures cibles. Le compilo
gcc d'Open est aussi un truc bizarre. Pour avoir le moins de
problème, j'utilise toujours le gcc mainstream officiel, pas celui
de la distribution. Mon code embarque du Fortran 9x, 2003, mais
aussi 77 ainsi que du C89 et maintenant du C99. Il me faut donc un
gcc au moins égal à 4.0 et un gfortran au moins égal à 4.3, et
là, ça devient franchement marrant. La dernière fois que j'ai dû
compiler un 4.3 ou 4.4 sous OpenBSD, ce n'était pas la joie, parce
que le compilo par défaut est un 3.x qui bootstrappe difficilement
un gcc 4.3. Et pourtant, j'ai déjà compilé gcc sur des architectures
largement plus exotique que OpenBSD/x86.
Je suis bien place pour te repondre, vu que je suis plus ou moins "responsable"
des gcc qui trainent dans l'arbre des ports.
T'es alle voir ce qu'il y avait dans ports/lang/gcc/4.3, au moins au niveau
patch, ou t'es vraiment completement maso et t'as tout fait a la main ?
Oui, le compilo Open est bizarre. C'est entre autres lie au fait que j'ai
depuis un certain temps laisse tomber l'idee d'avoir un jour toutes nos
modifs "upstream". Mark Kettenis s'obstine encore un peu. Mais c'est
tellement dur de passer les modifs dans GCC officiel FSF qu'on a a
moitie renonce !
Note que la plupart de tes soucis de compilation d'un GCC 4.3, on les a eu.
Selon le cas:
- soit c'est une branche trop vieille pour la FSF, et ils refusent les patchs
pour que ca compile out-of-the-box.
- soit ca tourne rapidement au bras de fer avec eux a partir du moment ou on
a des raisons (plus ou moins legitimes, mais passons...) de faire les choses
differemment, et qu'ils ne sont pas d'accord...
Rappel, lie a un de mes messages precedents. Ca me prend generalement dix fois
plus de temps pour arriver a remonter un patch upstream *et a le faire prendre
en compte* sur gcc que pour n'importe quel autre projet auquel je contribue...
Pour dériver un peu, lorsque je fais un bug report sur un point
précis, l'équipe de NetBSD ou de FreeBSD traite le problème dans un
délai raisonnable (le dernier que j'ai fait chez Free a été traité
en une semaine). La même chose chez Open me revient avec un "won't
fix" ou un magnifique "ne sera pas implanté parce que non 'secure'"
pour le coup des symboles faibles pthread/sigaltstack
Il y a plein, plein de problemes connus dans pthreads! La solution, c'est
d'avoir des threads noyaux. Il y a Guenther qui bosse sur rthreads, mais
ca prend du temps... et pour les problemes que tu vois, si c'est trop
complique... ca bouffe du temps qui ne sera pas utilise pour faire avancer
rthreads...
Je ne te donnerai pas de delais, mais c'est un des gros chantiers sur lesquels
on espere bien avoir quelque chose un jour... si d'autres personnes competentes
s'y mettent, ca pourrait avancer plus vite.
In article ,
JKB wrote:Le 16-05-2010, ? propos de
Re: [C99] gcc et fonctions 'inline',
Marc Espie ?crivait dans fr.comp.lang.c :Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
Il y a effectivement des problèmes de locales, mais ça se contourne
(assez) facilement. Les problèmes que j'ai sont surtout liés à
l'utilisation des threads POSIX sous OpenBSD (avec sigaltstack pour
récupérer les débordements de pile et les signaux) ainsi que la
gestion des signaux par thread.
Sur le long terme, on espere bien passer a uthread un jour prochain. Les
soucis que tu vois sont lies a pthread.
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)Pas sur les points qui m'intéressent. Mes bugs reports datent au
moins de la 4.2 sans que ça progresse significativement. Tu me diras
que je n'ai qu'à ne pas torturer les specs POSIX comme je le fais et
tu auras sans doute raison. Le problème est que je n'ai pas vraiment
le choix pour avoir quelque chose d'à-peu-près portable sur mes
systèmes d'exploitation et architectures cibles. Le compilo
gcc d'Open est aussi un truc bizarre. Pour avoir le moins de
problème, j'utilise toujours le gcc mainstream officiel, pas celui
de la distribution. Mon code embarque du Fortran 9x, 2003, mais
aussi 77 ainsi que du C89 et maintenant du C99. Il me faut donc un
gcc au moins égal à 4.0 et un gfortran au moins égal à 4.3, et
là, ça devient franchement marrant. La dernière fois que j'ai dû
compiler un 4.3 ou 4.4 sous OpenBSD, ce n'était pas la joie, parce
que le compilo par défaut est un 3.x qui bootstrappe difficilement
un gcc 4.3. Et pourtant, j'ai déjà compilé gcc sur des architectures
largement plus exotique que OpenBSD/x86.
Je suis bien place pour te repondre, vu que je suis plus ou moins "responsable"
des gcc qui trainent dans l'arbre des ports.
T'es alle voir ce qu'il y avait dans ports/lang/gcc/4.3, au moins au niveau
patch, ou t'es vraiment completement maso et t'as tout fait a la main ?
Oui, le compilo Open est bizarre. C'est entre autres lie au fait que j'ai
depuis un certain temps laisse tomber l'idee d'avoir un jour toutes nos
modifs "upstream". Mark Kettenis s'obstine encore un peu. Mais c'est
tellement dur de passer les modifs dans GCC officiel FSF qu'on a a
moitie renonce !
Note que la plupart de tes soucis de compilation d'un GCC 4.3, on les a eu.
Selon le cas:
- soit c'est une branche trop vieille pour la FSF, et ils refusent les patchs
pour que ca compile out-of-the-box.
- soit ca tourne rapidement au bras de fer avec eux a partir du moment ou on
a des raisons (plus ou moins legitimes, mais passons...) de faire les choses
differemment, et qu'ils ne sont pas d'accord...
Rappel, lie a un de mes messages precedents. Ca me prend generalement dix fois
plus de temps pour arriver a remonter un patch upstream *et a le faire prendre
en compte* sur gcc que pour n'importe quel autre projet auquel je contribue...
Pour dériver un peu, lorsque je fais un bug report sur un point
précis, l'équipe de NetBSD ou de FreeBSD traite le problème dans un
délai raisonnable (le dernier que j'ai fait chez Free a été traité
en une semaine). La même chose chez Open me revient avec un "won't
fix" ou un magnifique "ne sera pas implanté parce que non 'secure'"
pour le coup des symboles faibles pthread/sigaltstack
Il y a plein, plein de problemes connus dans pthreads! La solution, c'est
d'avoir des threads noyaux. Il y a Guenther qui bosse sur rthreads, mais
ca prend du temps... et pour les problemes que tu vois, si c'est trop
complique... ca bouffe du temps qui ne sera pas utilise pour faire avancer
rthreads...
Je ne te donnerai pas de delais, mais c'est un des gros chantiers sur lesquels
on espere bien avoir quelque chose un jour... si d'autres personnes competentes
s'y mettent, ca pourrait avancer plus vite.
Note que la plupart de tes soucis de compilation d'un GCC 4.3, on les a eu.
Selon le cas:
- soit c'est une branche trop vieille pour la FSF, et ils refusent les patchs
pour que ca compile out-of-the-box.
- soit ca tourne rapidement au bras de fer avec eux a partir du moment ou on
a des raisons (plus ou moins legitimes, mais passons...) de faire les choses
differemment, et qu'ils ne sont pas d'accord...
Je dois être un peu idiot. Lorsque je récupère les sources d'un GCC
sur le ftp officiel et qu'une cible openbsd/x86 existe, je suppose
peut-être hâtivement que le compilo en question doit pouvoir être
au moins compilé sur OpenBSD...
Note que la plupart de tes soucis de compilation d'un GCC 4.3, on les a eu.
Selon le cas:
- soit c'est une branche trop vieille pour la FSF, et ils refusent les patchs
pour que ca compile out-of-the-box.
- soit ca tourne rapidement au bras de fer avec eux a partir du moment ou on
a des raisons (plus ou moins legitimes, mais passons...) de faire les choses
differemment, et qu'ils ne sont pas d'accord...
Je dois être un peu idiot. Lorsque je récupère les sources d'un GCC
sur le ftp officiel et qu'une cible openbsd/x86 existe, je suppose
peut-être hâtivement que le compilo en question doit pouvoir être
au moins compilé sur OpenBSD...
Note que la plupart de tes soucis de compilation d'un GCC 4.3, on les a eu.
Selon le cas:
- soit c'est une branche trop vieille pour la FSF, et ils refusent les patchs
pour que ca compile out-of-the-box.
- soit ca tourne rapidement au bras de fer avec eux a partir du moment ou on
a des raisons (plus ou moins legitimes, mais passons...) de faire les choses
differemment, et qu'ils ne sont pas d'accord...
Je dois être un peu idiot. Lorsque je récupère les sources d'un GCC
sur le ftp officiel et qu'une cible openbsd/x86 existe, je suppose
peut-être hâtivement que le compilo en question doit pouvoir être
au moins compilé sur OpenBSD...