29 Jan
2007
29 Jan
'07
9:19 a.m.
>> "BP" == Benoit Perrot
<benoit(a)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.
29 Jan
29 Jan
7:33 p.m.
New subject: 2: Original creation of argp/.
On 2007-01-29, Akim Demaille <akim(a)lrde.epita.fr> wrote:
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
Je l'applique dans tc ou dans le repos dédié à argp? En fait ça
devrait peut-être même remonter chez les mainteneurs de la glibc... 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.
--
SIGOURE Benoit aka Tsuna (SUSv3 compliant)
_____ "On a long enough timeline, the survival rate
/EPITA\ Promo 2008.CSI/ACU/YAKA for everyone drops to zero" -- Jack.
>>
"BP" == Benoit Perrot <benoit(a)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. 
30 Jan
30 Jan
10:47 a.m.
New subject: 2: Original creation of argp/.
Tsuna <tsuna(a)warszawa.lrde.epita.fr> writes:
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.
On 2007-01-29, Akim Demaille
<akim(a)lrde.epita.fr> wrote:
>> "BP" == Benoit Perrot
<benoit(a)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 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.
2 Feb
2 Feb
9:39 a.m.
New subject: 2: Original creation of argp/.
>> "T" == Tsuna
<tsuna(a)warszawa.lrde.epita.fr> writes:
Voilà un patch pour corriger le problème:
Merci !
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
Je l'applique dans tc ou dans le repos dédié à
argp?
Ce dernier. Puis abonner tc et vcn.
En fait ça devrait peut-être même remonter chez les
mainteneurs de
la glibc... 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.
Exact.
Ceci n'est pas argp de la glibc, c'est standalone-argp, vaguement
maintenu par Niels Möller (nisse(a)lysator.liu.se). Il faudrait le
contacter pour savoir s'il a une version plus à jour.
6552
days inactive
6556
days old
3 comments
3 participants
participants (3)
-
Akim Demaille -
Roland Levillain -
Tsuna