Error building run2 from source package in win7

Error building run2 from source package in win7

[David Sastre]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Hello,

This error shows up when trying to build run2-0.4.0-1-src on

CYGWIN_NT-6.1 win7 1.7.10s(0.244/5/3) 20110510 19:08:34 i686 Cygwin

cc1: warnings being treated as errors
/usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c: In function 'run2_strtol':
/usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c:423:3: error: passing argument 3 of '__assert_func' discards qualifiers from pointer target type
/usr/include/assert.h:41:6: note: expected 'char *' but argument is of type 'const char *'
make[1]: *** [util.lo] Error 1

Any other info I could provide?

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: Error building run2 from source package in win7

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On 05/23/2011 11:17 AM, David Sastre wrote:
> Hello,
> 
> This error shows up when trying to build run2-0.4.0-1-src on
> 
> CYGWIN_NT-6.1 win7 1.7.10s(0.244/5/3) 20110510 19:08:34 i686 Cygwin
> 
> cc1: warnings being treated as errors
> /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c: In function 'run2_strtol':
> /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c:423:3: error: passing argument 3 of '__assert_func' discards qualifiers from pointer target type
> /usr/include/assert.h:41:6: note: expected 'char *' but argument is of type 'const char *'

The signature in assert.h uses 'const char *'; I would have to suspect
that somewhere in your build process you have a stray:

#define const

getting in the way, and that this is thus a bug in the run2 sources and
not in cygwin headers.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Error building run2 from source package in win7

[Charles Wilson]

On 5/23/2011 1:22 PM, Eric Blake wrote:
> On 05/23/2011 11:17 AM, David Sastre wrote:
>> cc1: warnings being treated as errors
>> /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c: In function 'run2_strtol':
>> /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c:423:3: error: passing argument 3 of '__assert_func' discards qualifiers from pointer target type
>> /usr/include/assert.h:41:6: note: expected 'char *' but argument is of type 'const char *'
> 
> The signature in assert.h uses 'const char *'; I would have to suspect
> that somewhere in your build process you have a stray:
> 
> #define const
> 
> getting in the way,

I think this is the only possibility, because...

> and that this is thus a bug in the run2 sources and
> not in cygwin headers.

...the code does this:

int
run2_strtol(char *arg, long *value)
{
  char *endptr;
  int errno_save = errno;

  assert(arg!=NULL);

However, the stringization of the expression 'arg!=NULL' is passed as
arg #4 (and the expression itself doesn't appear in the argument list of
__assert_func at all; see definition below).  Anyway, the #3 argument of
__assert_func is __ASSERT_FUNC:

# define assert(__e) ((__e) ? (void)0 : \
   __assert_func (__FILE__, __LINE__, \
   __ASSERT_FUNC, #__e))

and __ASSERT_FUNC is defined as
	__PRETTY_FUNCTION__
	__func__
or 	__FUNCTION__
depending on the compiler and various flags.  Now, since these are
built-ins, the "signature" is fixed: they are all const char*.  So the
only way you could get this warning/error is if assert.h is "messed up"
somehow...e.g. as Eric suggests, because an earlier header has #defined
const away before the following decl in assert.h is parsed:

void _EXFUN(__assert_func, (const char *, int, const char *,
  const char *) _ATTRIBUTE ((__noreturn__)));




Now, where could a #define const occur?

$ find ${run2_srcdir} -type f |\
      xargs grep const | grep define | grep '#'
./configure:$as_echo "#define const /**/" >>confdefs.h

...more checking...Ah, this is part of the configure macro AC_C_CONST.

hmm...maybe the OP should check his generated config.h file for the
offending def.  If it's there, a quick look inside config.log should
tell you why 'checking for an ANSI C-conforming const' is reporting 'no'.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Error building run2 from source package in win7

[David Sastre]

[-- Attachment #1: Type: text/plain, Size: 4332 bytes --]

On Mon, May 23, 2011 at 02:33:56PM -0400, Charles Wilson wrote:
> On 5/23/2011 1:22 PM, Eric Blake wrote:
> > On 05/23/2011 11:17 AM, David Sastre wrote:
> >> cc1: warnings being treated as errors
> >> /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c: In function 'run2_strtol':
> >> /usr/src/run2-0.4.0-1-src/run2-0.4.0-1/src/run2-0.4.0/lib/util.c:423:3: error: passing argument 3 of '__assert_func' discards qualifiers from pointer target type
> >> /usr/include/assert.h:41:6: note: expected 'char *' but argument is of type 'const char *'
> > 
> > The signature in assert.h uses 'const char *'; I would have to suspect
> > that somewhere in your build process you have a stray:
> > 
> > #define const
> > 
> > getting in the way,
> 
> I think this is the only possibility, because...
> 
> > and that this is thus a bug in the run2 sources and
> > not in cygwin headers.

FWIW, I never meant to have found a bug in cygwin nor in the run2 sources.
I'm just failing to build it and I hoped your wisdom might help me.

> ...the code does this:
> 
> int
> run2_strtol(char *arg, long *value)
> {
>   char *endptr;
>   int errno_save = errno;
> 
>   assert(arg!=NULL);
> 
> However, the stringization of the expression 'arg!=NULL' is passed as
> arg #4 (and the expression itself doesn't appear in the argument list of
> __assert_func at all; see definition below).  Anyway, the #3 argument of
> __assert_func is __ASSERT_FUNC:
> 
> # define assert(__e) ((__e) ? (void)0 : \
>    __assert_func (__FILE__, __LINE__, \
>    __ASSERT_FUNC, #__e))
> 
> and __ASSERT_FUNC is defined as
> 	__PRETTY_FUNCTION__
> 	__func__
> or 	__FUNCTION__
> depending on the compiler and various flags.  Now, since these are
> built-ins, the "signature" is fixed: they are all const char*.  So the
> only way you could get this warning/error is if assert.h is "messed up"
> somehow...e.g. as Eric suggests, because an earlier header has #defined
> const away before the following decl in assert.h is parsed:
> 
> void _EXFUN(__assert_func, (const char *, int, const char *,
>   const char *) _ATTRIBUTE ((__noreturn__)));
 
Thanks both for the educational explanation. 
 
> Now, where could a #define const occur?
> 
> $ find ${run2_srcdir} -type f |\
>       xargs grep const | grep define | grep '#'
> ./configure:$as_echo "#define const /**/" >>confdefs.h
> 
> ...more checking...Ah, this is part of the configure macro AC_C_CONST.
> 
> hmm...maybe the OP should check his generated config.h file for the
> offending def.  If it's there, a quick look inside config.log should
> tell you why 'checking for an ANSI C-conforming const' is reporting 'no'.

$ grep -nR "define const" run2-0.4.0-1/build/config.h
152:#define const /**/

From the config.log:

configure:12737: checking for an ANSI C-conforming const
configure:12802: gcc -c -Wall -Werror  conftest.c >&5
cc1: warnings being treated as errors
conftest.c: In function 'main':
conftest.c:69:10: error: 't' is used uninitialized in this function
conftest.c:85:23: error: 'b' may be used uninitialized in this function
configure:12802: $? = 1
configure: failed program was:
(snipped defines and removed comments)
| int
| main ()
| {
| #ifndef __cplusplus
|   typedef int charset[2];
|   const charset cs;
|   char const *const *pcpcc;
|   char **ppc;
|   struct point {int x, y;};
|   static struct point const zero = {0,0};
|   const char *g = "string";
|   pcpcc = &g + (g ? g-g : 0);
|   ++pcpcc;
|   ppc = (char**) pcpcc;
|   pcpcc = (char const *const *) ppc;
|   {
|     char *t;
|     char const *s = 0 ? (char *) 0 : (char const *) 0;
|
|     *t++ = 0;
|     if (s) return 0;
|   }
|   {
|     int x[] = {25, 17};
|     const int *foo = &x[0];
|     ++foo;
|   }
|   {
|     typedef const int *iptr;
|     iptr p = 0;
|     ++p;
|   }
|   {
|        "k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. */
|     struct s { int j; const int *ap[3]; };
|     struct s *b; b->j = 5;
|   }
|   {
|     const int foo = 10;
|     if (!foo) return 0;
|   }
|   return !cs[0] && !zero.x;
| #endif
|
|   ;
|   return 0;
| }
configure:12809: result: no

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: Error building run2 from source package in win7

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On 05/24/2011 12:38 PM, David Sastre wrote:
> From the config.log:
> 
> configure:12737: checking for an ANSI C-conforming const
> configure:12802: gcc -c -Wall -Werror  conftest.c >&5

There's your problem.

Autoconf-generated configure scripts do _NOT_ support -Werror; it is too
problematic to ever guarantee that all possible warnings from all
possible gcc versions will always be silenced.

It is permissible to configure without -Werror, and add it later via
'make CFLAGS="-Werror ..."', once configure has found correct results.
But by injecting -Werror too soon into the process, you've made
configure guess a wrong result:

> cc1: warnings being treated as errors
> conftest.c: In function 'main':
> conftest.c:69:10: error: 't' is used uninitialized in this function
> conftest.c:85:23: error: 'b' may be used uninitialized in this function
...
> configure:12809: result: no

with disastrous consequences on the rest of the project compilation.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Error building run2 from source package in win7

[Charles Wilson]

On 5/24/2011 2:38 PM, David Sastre wrote:

>> hmm...maybe the OP should check his generated config.h file for the
>> offending def.  If it's there, a quick look inside config.log should
>> tell you why 'checking for an ANSI C-conforming const' is reporting 'no'.
> 
> $ grep -nR "define const" run2-0.4.0-1/build/config.h
> 152:#define const /**/
> 
> From the config.log:
> 
> configure:12737: checking for an ANSI C-conforming const
> configure:12802: gcc -c -Wall -Werror  conftest.c >&5
> cc1: warnings being treated as errors
> conftest.c: In function 'main':
> conftest.c:69:10: error: 't' is used uninitialized in this function
> conftest.c:85:23: error: 'b' may be used uninitialized in this function

Looks like a possible bug in autoconf, which is where the definition of
AC_C_CONST comes from -- or they might define this as PIBKAC (see
below).  The test really ought to be -Wall -Werror friendly, but that's
up to the autoconf guys.

Here's a simple test case:

configure.ac
AC_INIT([test])
AC_CONFIG_SRCDIR([configure.ac])
AC_C_CONST

$ autoconf
$ ./configure
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for an ANSI C-conforming const... yes


$ ./configure CFLAGS="-Wall -Werror"
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for an ANSI C-conforming const... yes

Hmm...that works fine.  What about:

$ ./configure CC="gcc -Wall -Werror"
checking for gcc... gcc -Wall -Werror
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -Wall -Werror accepts -g... yes
checking for gcc -Wall -Werror option to accept ISO C89... none needed
checking for an ANSI C-conforming const... no


A-ha!

Don't set -Werror as part of $CC, set it in $CFLAGS instead.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Error building run2 from source package in win7

[David Sastre]

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

On Tue, May 24, 2011 at 02:59:11PM -0400, Charles Wilson wrote:
> On 5/24/2011 2:38 PM, David Sastre wrote:
> 
> >> hmm...maybe the OP should check his generated config.h file for the
> >> offending def.  If it's there, a quick look inside config.log should
> >> tell you why 'checking for an ANSI C-conforming const' is reporting 'no'.
> > 
> > $ grep -nR "define const" run2-0.4.0-1/build/config.h
> > 152:#define const /**/
> > 
> > From the config.log:
> > 
> > configure:12737: checking for an ANSI C-conforming const
> > configure:12802: gcc -c -Wall -Werror  conftest.c >&5
> > cc1: warnings being treated as errors
> > conftest.c: In function 'main':
> > conftest.c:69:10: error: 't' is used uninitialized in this function
> > conftest.c:85:23: error: 'b' may be used uninitialized in this function
> 
> Looks like a possible bug in autoconf, which is where the definition of
> AC_C_CONST comes from -- or they might define this as PIBKAC (see
> below).  The test really ought to be -Wall -Werror friendly, but that's
> up to the autoconf guys.

(snip) 

> $ ./configure CC="gcc -Wall -Werror"
> checking for gcc... gcc -Wall -Werror
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.exe
> checking for suffix of executables... .exe
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc -Wall -Werror accepts -g... yes
> checking for gcc -Wall -Werror option to accept ISO C89... none needed
> checking for an ANSI C-conforming const... no
> 
> A-ha!
> 
> Don't set -Werror as part of $CC, set it in $CFLAGS instead.

Which is what is defined in the *.cygport's src_compile func:

src_compile() {
        cd ${S}
        cygautoreconf
        cd ${B}
        cygconf CFLAGS="-Wall -Werror"
        cygmake
}

And I'm doing nothing but running 'cygport *.cygport all'.

This test is failing for me:

$ cat configure.ac
AC_INIT([test])
AC_CONFIG_SRCDIR([configure.ac])
AC_C_CONST

$ autoconf
$ ./configure CFLAGS="-Wall -Werror"
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for an ANSI C-conforming const... no

for the same reasons (config.log):

configure:2563: gcc -c -Wall -Werror  conftest.c >&5
cc1: warnings being treated as errors
conftest.c: In function 'main':
conftest.c:38:10: error: 't' is used uninitialized in this function
conftest.c:54:23: error: 'b' may be used uninitialized in this
function
configure:2563: $? = 1

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: Error building run2 from source package in win7

[Charles Wilson]

On 5/24/2011 3:53 PM, David Sastre wrote:
> On Tue, May 24, 2011 at 02:59:11PM -0400, Charles Wilson wrote:
>> A-ha!
>>
>> Don't set -Werror as part of $CC, set it in $CFLAGS instead.
> 
> Which is what is defined in the *.cygport's src_compile func:
> 
> src_compile() {
>         cd ${S}
>         cygautoreconf
>         cd ${B}
>         cygconf CFLAGS="-Wall -Werror"
>         cygmake
> }
> 
> And I'm doing nothing but running 'cygport *.cygport all'.

Well, Eric is the real expert, and he says don't set the warning flags
until the cygmake line, so that's first.  However, I assume the
incantation above worked in the past for the original author of the
.cygport(5) file, so why's it breaking for you?

Second, why does the STC below not work for you, when it worked for me?

> for the same reasons (config.log):
> 
> configure:2563: gcc -c -Wall -Werror  conftest.c >&5
> cc1: warnings being treated as errors
> conftest.c: In function 'main':
> conftest.c:38:10: error: 't' is used uninitialized in this function
> conftest.c:54:23: error: 'b' may be used uninitialized in this
> function
> configure:2563: $? = 1

Well, looking at my config.log, I too have:

configure:2498: checking for an ANSI C-conforming const
configure:2563: gcc -c -Wall -Werror  conftest.c >&5
                       ^^^^^^^^^^^^^
configure:2563: $? = 0
configure:2570: result: yes

but we already know that this conftest.c is not -Wall -Werror clean --
or, at least, that YOUR conftest.c is not clean.

Digging deeper in my configure, I find that the test uses the shell
function ac_fn_c_try_compile(), and that shell function has an
interesting bit of code:

1340      test -z "$ac_c_werror_flag" ||
1341      test ! -s conftest.err
1342        } && test -s conftest.$ac_objext; then :
1343   ac_retval=0

Hmmm...it's checking something to do with a Werror flag!  Maybe there's
a workaround, but (a) is only activated if the -Werror is in CFLAGS, not
CC -- otherwise *I* would have passed the STC with CC='gcc -Wall
-Werror' but I didn't, and (b) its only present in specific (newer?)
versions of autoconf, and you and I are using different versions.

Here's the first 3 lines of my configure script:

   1 #! /bin/sh
   2 # Guess values for system-dependent variables and create Makefiles.
   3 # Generated by GNU Autoconf 2.68.

What's yours say?

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Error building run2 from source package in win7

[David Sastre]

[-- Attachment #1: Type: text/plain, Size: 3607 bytes --]

On Tue, May 24, 2011 at 05:10:37PM -0400, Charles Wilson wrote:
> On 5/24/2011 3:53 PM, David Sastre wrote:
> > On Tue, May 24, 2011 at 02:59:11PM -0400, Charles Wilson wrote:
> >> A-ha!
> >>
> >> Don't set -Werror as part of $CC, set it in $CFLAGS instead.
> > 
> > Which is what is defined in the *.cygport's src_compile func:
> > 
> > src_compile() {
> >         cd ${S}
> >         cygautoreconf
> >         cd ${B}
> >         cygconf CFLAGS="-Wall -Werror"
> >         cygmake
> > }
> > 
> > And I'm doing nothing but running 'cygport *.cygport all'.
> 
> Well, Eric is the real expert, and he says don't set the warning flags
> until the cygmake line, so that's first.  However, I assume the
> incantation above worked in the past for the original author of the
> .cygport(5) file, so why's it breaking for you?
> 
> Second, why does the STC below not work for you, when it worked for me?
> 
> > for the same reasons (config.log):
> > 
> > configure:2563: gcc -c -Wall -Werror  conftest.c >&5
> > cc1: warnings being treated as errors
> > conftest.c: In function 'main':
> > conftest.c:38:10: error: 't' is used uninitialized in this function
> > conftest.c:54:23: error: 'b' may be used uninitialized in this
> > function
> > configure:2563: $? = 1
> 
> Well, looking at my config.log, I too have:
> 
> configure:2498: checking for an ANSI C-conforming const
> configure:2563: gcc -c -Wall -Werror  conftest.c >&5
>                        ^^^^^^^^^^^^^
> configure:2563: $? = 0
> configure:2570: result: yes
> 
> but we already know that this conftest.c is not -Wall -Werror clean --
> or, at least, that YOUR conftest.c is not clean.
> 
> Digging deeper in my configure, I find that the test uses the shell
> function ac_fn_c_try_compile(), and that shell function has an
> interesting bit of code:
> 
> 1340      test -z "$ac_c_werror_flag" ||
> 1341      test ! -s conftest.err
> 1342        } && test -s conftest.$ac_objext; then :
> 1343   ac_retval=0
> 
> Hmmm...it's checking something to do with a Werror flag!  Maybe there's
> a workaround, but (a) is only activated if the -Werror is in CFLAGS, not
> CC -- otherwise *I* would have passed the STC with CC='gcc -Wall
> -Werror' but I didn't, and (b) its only present in specific (newer?)
> versions of autoconf, and you and I are using different versions.
> 
> Here's the first 3 lines of my configure script:
> 
>    1 #! /bin/sh
>    2 # Guess values for system-dependent variables and create Makefiles.
>    3 # Generated by GNU Autoconf 2.68.
> 
> What's yours say?

Autoconf version matches yours:

$ cygcheck -c autoconf2.5
Cygwin Package Information
Package              Version        Status
autoconf2.5          2.68-1         OK

$ head -3 configure
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.68 for run2 0.4.0.

Moving the -Werror flag to the cygmake step did the trick:

$ diff -u run2-0.4.0-1.cygport.orig run2-0.4.0-1.cygport
--- run2-0.4.0-1.cygport.orig   2009-12-29 07:30:19.000000000 +0100
+++ run2-0.4.0-1.cygport        2011-05-25 11:11:51.139200000 +0200
@@ -11,7 +11,7 @@
        cd ${S}
        cygautoreconf
        cd ${B}
-       cygconf CFLAGS="-Wall -Werror"
-       cygmake
+       cygconf CFLAGS="-Wall" 
+       cygmake CFLAGS="-Werror"
 }

checking for an ANSI C-conforming const... yes

I've been able to compile without problems.

Thanks for your time.

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]