[GRASS-dev] GRASS 7 swig compile warnings and errors

Hi,

I get warnings and errors in swig/python/:

cd swig/python/
make
...
gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -g
-Wall -fno-common -mtune=nocona -m64 -minline-all-stringops -fPIC
-I/usr/include/python2.5 -I/usr/include/python2.5
-DPACKAGE=\""grasslibs"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/utils_wrap.o -c utils_wrap.c
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2564: warning: format '%d' expects type 'int', but
argument 3 has type 'Py_ssize_t'
...
/usr/bin/swig -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-python -module date -shadow date.i
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/datetime.h:18:
Warning(314): 'from' is a python keyword, renaming to '_from'

gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -g
-Wall -fno-common -mtune=nocona -m64 -minline-all-stringops -fPIC
-I/usr/include/python2.5 -I/usr/include/python2.5
-DPACKAGE=\""grasslibs"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/date_wrap.o -c date_wrap.c
date_wrap.c: In function 'pyseq_to_ptr':
date_wrap.c:2563: warning: format '%d' expects type 'int', but
argument 3 has type 'Py_ssize_t'
...
/usr/bin/swig -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-python -module grass -shadow grass.i
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:39:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:587:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:591:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:593:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:594:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:595:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:596:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:604:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:607:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:608:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:617:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:618:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:619:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:625:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:626:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:627:
Warning(451): Setting a const char * variable may leak memory.
gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -g
-Wall -fno-common -mtune=nocona -m64 -minline-all-stringops -fPIC
-I/usr/include/python2.5 -I/usr/include/python2.5
-DPACKAGE=\""grasslibs"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/grass_wrap.o -c grass_wrap.c
grass_wrap.c: In function 'pyseq_to_ptr':
grass_wrap.c:2620: warning: format '%d' expects type 'int', but
argument 3 has type 'Py_ssize_t'
grass_wrap.c: In function '_wrap_G_vasprintf':
grass_wrap.c:18166: error: incompatible types in assignment
make[1]: *** [OBJ.x86_64-unknown-linux-gnu/grass_wrap.o] Error 1
make[1]: Leaving directory `/home/neteler/grass70/swig/python'
make: *** [default] Error 2

Looking around grass_wrap.c:2620

static void *pyseq_to_ptr(PyObject *input, int data_type)
{
        size_t size;
        Py_ssize_t len;
...
        len = PySequence_Length(input);
        array = malloc(len * size);

        fprintf(stderr, "sequence length is %d\n", len);
...

swig -version
SWIG Version 1.3.36

Linux mandrivalinux.local 2.6.27.7-server-1mnb #1 SMP Thu Dec 11
17:41:52 EST 2008 x86_64Intel(R) Core(TM)2 CPU T5500 @
1.66GHz GNU/Linux

cat /etc/issue
Mandriva Linux release 2009.0 (Official) for x86_64
Kernel 2.6.27.7-server-1mnb on a Dual-processor x86_64 / \l

Python 2.5.2 (r252:60911, Jan 8 2009, 13:05:10)

I have no idea how to fix this.

Markus

Markus Neteler wrote:

I get warnings and errors in swig/python/:

grass_wrap.c: In function '_wrap_G_vasprintf':
grass_wrap.c:18166: error: incompatible types in assignment

No idea what's causing this. For me, line 18166 is:

      arg3 = *((va_list *)(argp3));

with arg3 defined as:

  va_list arg3 ;

The others are just warnings.

Looking around grass_wrap.c:2620

        fprintf(stderr, "sequence length is %d\n", len);

That's debug code, which I have removed (r35480).

--
Glynn Clements <glynn@gclements.plus.com>

On Sun, Jan 18, 2009 at 8:11 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

I get warnings and errors in swig/python/:

grass_wrap.c: In function '_wrap_G_vasprintf':
grass_wrap.c:18166: error: incompatible types in assignment

No idea what's causing this. For me, line 18166 is:

     arg3 = *((va_list *)(argp3));

with arg3 defined as:

va_list arg3 ;

The others are just warnings.

I have

    if (!argp3) {
      SWIG_exception_fail(SWIG_ValueError, "invalid null reference "
"in method '" "G_vasprintf" "', argument " "3"" of type '"
"va_list""'");
    } else {
      arg3 = *((va_list *)(argp3));
    }

but it gives:

gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -g
-Wall -fno-common -mtune=nocona -m64 -minline-all-stringops -fPIC
-I/usr/include/python2.5 -I/usr/include/python2.5
-DPACKAGE=\""grasslibs"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/grass_wrap.o -c grass_wrap.c
grass_wrap.c: In function '_wrap_G_vasprintf':
grass_wrap.c:18164: error: incompatible types in assignment

Looking around grass_wrap.c:2620

        fprintf(stderr, "sequence length is %d\n", len);

That's debug code, which I have removed (r35480).

Ok, this part now compiles.

Markus

Markus Neteler wrote:

>> I get warnings and errors in swig/python/:
>
>> grass_wrap.c: In function '_wrap_G_vasprintf':
>> grass_wrap.c:18166: error: incompatible types in assignment
>
> No idea what's causing this. For me, line 18166 is:
>
> arg3 = *((va_list *)(argp3));
>
> with arg3 defined as:
>
> va_list arg3 ;
>
> The others are just warnings.

I have

    if (!argp3) {
      SWIG_exception_fail(SWIG_ValueError, "invalid null reference "
"in method '" "G_vasprintf" "', argument " "3"" of type '"
"va_list""'");
    } else {
      arg3 = *((va_list *)(argp3));
    }

What does the declaration of arg3 look like?

--
Glynn Clements <glynn@gclements.plus.com>

On Mon, Jan 19, 2009 at 12:37 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

>> I get warnings and errors in swig/python/:
>
>> grass_wrap.c: In function '_wrap_G_vasprintf':
>> grass_wrap.c:18166: error: incompatible types in assignment
>
> No idea what's causing this. For me, line 18166 is:
>
> arg3 = *((va_list *)(argp3));
>
> with arg3 defined as:
>
> va_list arg3 ;
>
> The others are just warnings.

I have

    if (!argp3) {
      SWIG_exception_fail(SWIG_ValueError, "invalid null reference "
"in method '" "G_vasprintf" "', argument " "3"" of type '"
"va_list""'");
    } else {
      arg3 = *((va_list *)(argp3));
    }

What does the declaration of arg3 look like?

The function header looks like this:

SWIGINTERN PyObject *_wrap_G_vasprintf(PyObject *SWIGUNUSEDPARM(self),
PyObject *args) {
  PyObject *resultobj = 0;
  char **arg1 = (char **) 0 ;
  char *arg2 = (char *) 0 ;
  va_list arg3 ; <<<----
  void *argp1 = 0 ;
  int res1 = 0 ;
  int res2 ;
  char *buf2 = 0 ;
  int alloc2 = 0 ;
  void *argp3 ;
  int res3 = 0 ;
  PyObject * obj0 = 0 ;
  PyObject * obj1 = 0 ;
  PyObject * obj2 = 0 ;
  int result;

Markus

Markus Neteler wrote:

>> >> I get warnings and errors in swig/python/:
>> >
>> >> grass_wrap.c: In function '_wrap_G_vasprintf':
>> >> grass_wrap.c:18166: error: incompatible types in assignment

>> arg3 = *((va_list *)(argp3));

> What does the declaration of arg3 look like?

  va_list arg3 ; <<<----

So assigning an expression of type va_list to a variable of type
va_list results in an "incompatible types in assignment" error from
the compiler?

I can only suggest taking this up with the gcc maintainers; I have no
clue.

--
Glynn Clements <glynn@gclements.plus.com>

On Mon, Jan 19, 2009 at 5:19 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

>> >> I get warnings and errors in swig/python/:
>> >
>> >> grass_wrap.c: In function '_wrap_G_vasprintf':
>> >> grass_wrap.c:18166: error: incompatible types in assignment

>> arg3 = *((va_list *)(argp3));

> What does the declaration of arg3 look like?

  va_list arg3 ; <<<----

So assigning an expression of type va_list to a variable of type
va_list results in an "incompatible types in assignment" error from
the compiler?

I can only suggest taking this up with the gcc maintainers; I have no
clue.

I found this:
http://www.swig.org/Doc1.3/SWIGDocumentation.html#Varargs_nn8
-> 13.7 Wrapping of va_list

I don't know if that's related. Also this from a ruby list:
http://rubyforge.org/pipermail/ruby-vpi-discuss/2007-August/000008.html
... mentioning a "type mismatch" error.

BTW, I am using gcc version 4.3.2 on 64bit. Is it only me having
this problem to compile swig/python/ ?

Markus

Markus Neteler wrote:

> So assigning an expression of type va_list to a variable of type
> va_list results in an "incompatible types in assignment" error from
> the compiler?
>
> I can only suggest taking this up with the gcc maintainers; I have no
> clue.

I found this:
http://www.swig.org/Doc1.3/SWIGDocumentation.html#Varargs_nn8
-> 13.7 Wrapping of va_list

I don't know if that's related. Also this from a ruby list:
http://rubyforge.org/pipermail/ruby-vpi-discuss/2007-August/000008.html
... mentioning a "type mismatch" error.

Okay. Given that you can't actually use that function from Python, the
simplest solution is probably to just hide the declaration from SWIG:

  +#ifndef SWIG
   int G_vasprintf(char **, const char *, va_list);
  +#endif

BTW, I am using gcc version 4.3.2 on 64bit. Is it only me having
this problem to compile swig/python/ ?

There's no problem with 3.4.6 on 32-bit.

--
Glynn Clements <glynn@gclements.plus.com>

On Tue, Jan 20, 2009 at 11:53 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

> So assigning an expression of type va_list to a variable of type
> va_list results in an "incompatible types in assignment" error from
> the compiler?
>
> I can only suggest taking this up with the gcc maintainers; I have no
> clue.

I found this:
http://www.swig.org/Doc1.3/SWIGDocumentation.html#Varargs_nn8
-> 13.7 Wrapping of va_list

I don't know if that's related. Also this from a ruby list:
http://rubyforge.org/pipermail/ruby-vpi-discuss/2007-August/000008.html
... mentioning a "type mismatch" error.

Okay. Given that you can't actually use that function from Python, the
simplest solution is probably to just hide the declaration from SWIG:

       +#ifndef SWIG
        int G_vasprintf(char **, const char *, va_list);
       +#endif

Done in r35522.
Now it compiles here, too.

Markus

BTW, I am using gcc version 4.3.2 on 64bit. Is it only me having
this problem to compile swig/python/ ?

There's no problem with 3.4.6 on 32-bit.

--
Glynn Clements <glynn@gclements.plus.com>