Tsuna tsuna@warszawa.lrde.epita.fr writes:
On 2007-01-29, Akim Demaille akim@lrde.epita.fr wrote:
"BP" == Benoit Perrot benoit@lrde.epita.fr writes:
Heummmm ... Par pure curiosité : je peux demander pourquoi ? :) (On compterais le maintenir ? ;)
Je pensais qu'il y avait un problème de portabilité, mais c'était un problème de distcc. Comme il est utilisé par tc et vaucanson, ça méritait son propre dépôt. De toutes façons les warnings commencent à me souler, si qq'1 pouvait s'en charger, ce serait cool.
Je viens de regarder vite fait et y'a pas grand chose à faire... en fait y'a un endroit où ils utilisent des unsigned char* et après ils font des strlen/strncmp dessus et GCC se plaint que ça diffère en signedness, et le reste c'est des arguments non utilisés qui déclenchent un warning malgré l'utilisation visiblement correctement de __attribute__ ((__unused__)).
Après une rapide investigation, il s'avère que leur test pendant leur configure pour vérifier si le compilo gère les __attribute__ est b0rken:
configure:20502: checking for __attribute__ configure:20538: gcc -c -g -O2 conftest.c >&5 conftest.c: In function 'main': conftest.c:33: error: invalid storage class for function 'foo' conftest.c:37: error: invalid storage class for function 'foo' configure:20544: $? = 1 configure: failed program was: | /* confdefs.h. */ | [SNIP pleins de #define PACKAGE_* et HAVE_*_H] | /* end confdefs.h. */ | | #include <stdlib.h> | | int | main () | { | | static void foo(void) __attribute__ ((noreturn)); | | static void __attribute__ ((noreturn)) | foo(void) | { | exit(1); | } | | ; | return 0; | } configure:20559: result: no
En testant à la mano, ce code compile si le code est en dehors du main. On peut virer une partie des warnings en corrigeant le test du configure.
Voilà un patch pour corriger le problème:
Index: argp/acinclude.m4
--- argp/acinclude.m4 (revision 2508) +++ argp/acinclude.m4 (working copy) @@ -282,10 +282,8 @@ AC_DEFUN([LSH_GCC_ATTRIBUTES], [AC_CACHE_CHECK(for __attribute__, lsh_cv_c_attribute, -[ AC_TRY_COMPILE([ +[ AC_COMPILE_IFELSE([AC_LANG_SOURCE([[ #include <stdlib.h> -], -[ static void foo(void) __attribute__ ((noreturn));
static void __attribute__ ((noreturn)) @@ -293,9 +291,10 @@ { exit(1); } -], -lsh_cv_c_attribute=yes, -lsh_cv_c_attribute=no)]) +]])],
[lsh_cv_c_attribute=yes],[lsh_cv_c_attribute=no])+])
AH_TEMPLATE([HAVE_GCC_ATTRIBUTE], [Define if the compiler understands __attribute__]) if test "x$lsh_cv_c_attribute" = "xyes"; then
Ça me semble bien. Effectivement, leur utilisation de AC_TRY_COMPILE a vraiment l'air erronée.
Je l'applique dans tc ou dans le repos dédié à argp?
A priori, je pense que les copies d'argp de TC et Vaucanson devraient disparaître des dépôts, et que le dépôt d'argp devrait être utilisé via svn:externals. Donc je pense qu'il vaut mieux corriger le dépôt.
En fait ça devrait peut-être même remonter chez les mainteneurs de la glibc...
True, true. Au passage, a-t-on une version récente de argp ? Sinon, on devrait sans doute se resynchroniser avec la libc avant d'entreprendre des modifications et/ou des bug reports.
Je comprends pas comment ça pouvait détecter quoique ce soit leur truc. Peut-être que GCC autorisait les nested functions sans le mot clé ``auto'' avant. En tout cas c'est plus le cas sur un GCC récent.
C'est sans doute quelque chose de ce genre.