Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Tony Mechelynck
Trying to compile the latest vim 7.3a (74c8bba1d9e8) I get the following
error (the empty line after the command-line is an artefact to make it
more readable):

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
-I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
-I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
-I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
-I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
-I/usr/include/pango-1.0 -I/usr/include/gail-1.0
-I/usr/include/freetype2 -I/usr/include/atk-1.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
-D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
-DDEBUGGING  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
-I/usr/include/python2.6 -pthread -I/usr/include
-D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux
-DRUBY_VERSION=18  -o objects/if_perl.o auto/if_perl.c

In file included from /usr/include/netinet/in.h:24,
                  from
/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE/perl.h:1123,
                  from ./vim.h:2074,
                  from if_perl.xs:16:
/usr/include/stdint.h:52: error: duplicate ‘unsigned’
/usr/include/stdint.h:52: error: two or more data types in declaration
specifiers
make: *** [objects/if_perl.o] Error 1


I did what research I could and found the following:

src/if_perl.xs:16|#include "vim.h"

src/vim.h:2074|#include <perl.h>

.../perl.h:1122|#ifdef I_NETINET_IN
.../perl.h:1123|#   include <netinet/in.h>
.../perl.h:1124|#endif

/usr/include/netinet/in.h:24|#include <stdint.h>

/usr/include/stdint.h:31|#ifndef __uint32_t_defined
/usr/include/stdint.h:32|typedef unsigned int uint32_t;
/usr/include/stdint.h:33|# define __uint32_t_defined



Looks like the new encryption subsystem should have obeyed :help
style-names, as follows:

<quote>
Typedef'ed names should end in "_T": >
     typedef int some_T;
</quote>


Best regards,
Tony.
--
After the last of 16 mounting screws has been removed from an access
cover, it will be discovered that the wrong access cover has been
removed.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl (OOPS)

Tony Mechelynck
On 18/05/10 09:55, Tony Mechelynck wrote:
[...]
> /usr/include/stdint.h:31|#ifndef __uint32_t_defined
> /usr/include/stdint.h:32|typedef unsigned int uint32_t;
> /usr/include/stdint.h:33|# define __uint32_t_defined

these are of course lines 51 to 53

>
>
>
> Looks like the new encryption subsystem should have obeyed :help
> style-names, as follows:
>
> <quote>
> Typedef'ed names should end in "_T": >
> typedef int some_T;
> </quote>
>
>
> Best regards,
> Tony.

Sorry: if it's a Vim typedef it should end in _T

        typedef unsigned int uint32_T

if it's a define (which, on re-reading, seems more likely) it should be
in all caps

        #define UINT32 unsigned int

or else (probably recommended IIUC) <stdint.h> should have been included
before the point where the new code defines its 32-bit uint type.

Maybe add a configure check for how to define a "Vim unsigned 32-bit
integer", and whether to add an #include <stdint.h> if other compilers
do it otherwise?


Best regards,
Tony.
--
WOMAN:   King of the who?
ARTHUR:  The Britons.
WOMAN:   Who are the Britons?
ARTHUR:  Well, we all are. we're all Britons and I am your king.
                                   The Quest for the Holy Grail (Monty
Python)

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl (OOPS)

Jeff Horelick
I'm getting the same/similar build error as well on ArchLinux
compiling vim 7.3a (74c8bba1d9e8):

gcc -c -I. -Iproto -DHAVE_CONFIG_H     -march=native -mtune=native -O2
-pipe -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE  -fstack-
protector -I/usr/local/include -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64  -I/usr/lib/perl5/core_perl/CORE      -o objects/
window.o window.c
/usr/bin/perl -e 'unless ( $] >= 5.005 ) { for (qw(na defgv errgv))
{ print "#define PL_$_ $_\n" }}' > auto/if_perl.c
/usr/bin/perl /usr/share/perl5/core_perl/ExtUtils/xsubpp -prototypes -
typemap \
            /usr/share/perl5/core_perl/ExtUtils/typemap if_perl.xs >> auto/
if_perl.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H     -march=native -mtune=native -O2
-pipe -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE  -fstack-
protector -I/usr/local/include -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64  -I/usr/lib/perl5/core_perl/CORE      -o objects/
if_perl.o auto/if_perl.c
In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/include/
stdint.h:3:0,
                 from /usr/include/netinet/in.h:24,
                 from /usr/lib/perl5/core_perl/CORE/perl.h:1130,
                 from ./vim.h:2074,
                 from if_perl.xs:16:
/usr/include/stdint.h:52:23: error: duplicate ‘unsigned’
/usr/include/stdint.h:52:23: error: two or more data types in
declaration specifiers
make[1]: *** [objects/if_perl.o] Error 1



I'm also getting a similar error with python:

gcc -c -I. -Iproto -DHAVE_CONFIG_H     -march=native -mtune=native -O2
-pipe -D_FORTIFY_SOURCE=1     -I/usr/include/python2.6 -pthread    -o
objects/if_python.o  if_python.c
In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/include/
stdint.h:3:0,
                 from /usr/include/python2.6/pyport.h:7,
                 from /usr/include/python2.6/Python.h:58,
                 from if_python.c:49:
/usr/include/stdint.h:52:23: error: duplicate ‘unsigned’
/usr/include/stdint.h:52:23: error: two or more data types in
declaration specifiers
make[1]: *** [objects/if_python.o] Error 1


Regards,
JD

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl

Tony Mechelynck
On 18/05/10 11:12, JD wrote:

> I'm getting the same/similar build error as well on ArchLinux
> compiling vim 7.3a (74c8bba1d9e8):
>
> gcc -c -I. -Iproto -DHAVE_CONFIG_H     -march=native -mtune=native -O2
> -pipe -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE  -fstack-
> protector -I/usr/local/include -D_LARGEFILE_SOURCE -
> D_FILE_OFFSET_BITS=64  -I/usr/lib/perl5/core_perl/CORE      -o objects/
> window.o window.c
> /usr/bin/perl -e 'unless ( $]>= 5.005 ) { for (qw(na defgv errgv))
> { print "#define PL_$_ $_\n" }}'>  auto/if_perl.c
> /usr/bin/perl /usr/share/perl5/core_perl/ExtUtils/xsubpp -prototypes -
> typemap \
>    /usr/share/perl5/core_perl/ExtUtils/typemap if_perl.xs>>  auto/
> if_perl.c
> gcc -c -I. -Iproto -DHAVE_CONFIG_H     -march=native -mtune=native -O2
> -pipe -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE  -fstack-
> protector -I/usr/local/include -D_LARGEFILE_SOURCE -
> D_FILE_OFFSET_BITS=64  -I/usr/lib/perl5/core_perl/CORE      -o objects/
> if_perl.o auto/if_perl.c
> In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/include/
> stdint.h:3:0,
>                   from /usr/include/netinet/in.h:24,
>                   from /usr/lib/perl5/core_perl/CORE/perl.h:1130,
>                   from ./vim.h:2074,
>                   from if_perl.xs:16:
> /usr/include/stdint.h:52:23: error: duplicate ‘unsigned’
> /usr/include/stdint.h:52:23: error: two or more data types in
> declaration specifiers
> make[1]: *** [objects/if_perl.o] Error 1

Yeah, this one looks identical: at the same point for the same reason

>
>
>
> I'm also getting a similar error with python:
>
> gcc -c -I. -Iproto -DHAVE_CONFIG_H     -march=native -mtune=native -O2
> -pipe -D_FORTIFY_SOURCE=1     -I/usr/include/python2.6 -pthread    -o
> objects/if_python.o  if_python.c
> In file included from /usr/lib/gcc/i686-pc-linux-gnu/4.5.0/include/
> stdint.h:3:0,
>                   from /usr/include/python2.6/pyport.h:7,
>                   from /usr/include/python2.6/Python.h:58,
>                   from if_python.c:49:
> /usr/include/stdint.h:52:23: error: duplicate ‘unsigned’
> /usr/include/stdint.h:52:23: error: two or more data types in
> declaration specifiers
> make[1]: *** [objects/if_python.o] Error 1

...and I guess if I didn't see this one it's because I'm neither telling
make to compile several modules in parallel, nor to continue after an
error, and that if_perl.c got compiled before if_python.c, possibly for
as trivial a reason as alphabetic order (my Huge build is with -mzscheme
+perl +python +ruby +tcl). I have a hunch that a single fix will make
both errors disappear.

>
>
> Regards,
> JD
>


Best regards,
Tony.
--
"Why must you tell me all your secrets when it's hard enough to love
you knowing nothing?"
                -- Lloyd Cole and the Commotions

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Bram Moolenaar
In reply to this post by Tony Mechelynck

Tony Mechelynck wrote:

> Trying to compile the latest vim 7.3a (74c8bba1d9e8) I get the following
> error (the empty line after the command-line is an artefact to make it
> more readable):
>
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
> -I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
> -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
> -I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
> -I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
> -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
> -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
> -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
> -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
> -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
> -I/usr/include/pango-1.0 -I/usr/include/gail-1.0
> -I/usr/include/freetype2 -I/usr/include/atk-1.0
> -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
> -I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
> -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
> -DDEBUGGING  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
> -I/usr/include/python2.6 -pthread -I/usr/include
> -D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux
> -DRUBY_VERSION=18  -o objects/if_perl.o auto/if_perl.c
>
> In file included from /usr/include/netinet/in.h:24,
>                   from
> /usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE/perl.h:1123,
>                   from ./vim.h:2074,
>                   from if_perl.xs:16:
> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
> /usr/include/stdint.h:52: error: two or more data types in declaration
> specifiers
> make: *** [objects/if_perl.o] Error 1
>
>
> I did what research I could and found the following:
>
> src/if_perl.xs:16|#include "vim.h"
>
> src/vim.h:2074|#include <perl.h>
>
> .../perl.h:1122|#ifdef I_NETINET_IN
> .../perl.h:1123|#   include <netinet/in.h>
> .../perl.h:1124|#endif
>
> /usr/include/netinet/in.h:24|#include <stdint.h>
>
> /usr/include/stdint.h:31|#ifndef __uint32_t_defined
> /usr/include/stdint.h:32|typedef unsigned int uint32_t;
> /usr/include/stdint.h:33|# define __uint32_t_defined
>
> Looks like the new encryption subsystem should have obeyed :help
> style-names, as follows:
>
> <quote>
> Typedef'ed names should end in "_T": >
>      typedef int some_T;
> </quote>

Then we could not use the autoconf check, it always defines uint32_t.

I'll undefine uint32_t in vim.h, like it's done for netbeans.

--
hundred-and-one symptoms of being an internet addict:
64. The remote to the T.V. is missing...and you don't even care.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Dominique Pellé
On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar <[hidden email]> wrote:

>
> Tony Mechelynck wrote:
>
>> Trying to compile the latest vim 7.3a (74c8bba1d9e8) I get the following
>> error (the empty line after the command-line is an artefact to make it
>> more readable):
>>
>> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
>> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
>> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
>> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
>> -I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
>> -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
>> -I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
>> -I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
>> -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
>> -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
>> -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
>> -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
>> -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
>> -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
>> -I/usr/include/pango-1.0 -I/usr/include/gail-1.0
>> -I/usr/include/freetype2 -I/usr/include/atk-1.0
>> -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
>> -I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
>> -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
>> -DDEBUGGING  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>> -I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
>> -I/usr/include/python2.6 -pthread -I/usr/include
>> -D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux
>> -DRUBY_VERSION=18  -o objects/if_perl.o auto/if_perl.c
>>
>> In file included from /usr/include/netinet/in.h:24,
>>                   from
>> /usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE/perl.h:1123,
>>                   from ./vim.h:2074,
>>                   from if_perl.xs:16:
>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
>> /usr/include/stdint.h:52: error: two or more data types in declaration
>> specifiers
>> make: *** [objects/if_perl.o] Error 1
>>
>>
>> I did what research I could and found the following:
>>
>> src/if_perl.xs:16|#include "vim.h"
>>
>> src/vim.h:2074|#include <perl.h>
>>
>> .../perl.h:1122|#ifdef I_NETINET_IN
>> .../perl.h:1123|#   include <netinet/in.h>
>> .../perl.h:1124|#endif
>>
>> /usr/include/netinet/in.h:24|#include <stdint.h>
>>
>> /usr/include/stdint.h:31|#ifndef __uint32_t_defined
>> /usr/include/stdint.h:32|typedef unsigned int         uint32_t;
>> /usr/include/stdint.h:33|# define __uint32_t_defined
>>
>> Looks like the new encryption subsystem should have obeyed :help
>> style-names, as follows:
>>
>> <quote>
>> Typedef'ed names should end in "_T": >
>>      typedef int some_T;
>> </quote>
>
> Then we could not use the autoconf check, it always defines uint32_t.
>
> I'll undefine uint32_t in vim.h, like it's done for netbeans.


The same kind of error still happens when compiling if_python.c:

In file included from /usr/local/include/python2.6/pyport.h:7,
                 from /usr/local/include/python2.6/Python.h:58,
                 from if_python.c:49:
/usr/include/stdint.h:52: error: duplicate ‘unsigned’
/usr/include/stdint.h:52: error: two or more data types in declaration
specifiers


Shouldn't we include <stdint.h> (introduced in c99) rather than defining
int32_t when stdint.h is available?  With something more or less like...

#ifdef HAVE_STDINT_H
#include <stdint.h>
#else
/* Define to `unsigned int' or other type that is 32 bit.  */
#define uint32_t unsigned int
#endif

-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

James Vega-3
2010/5/18 Dominique Pellé <[hidden email]>:

> On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar <[hidden email]> wrote:
>>
>> Tony Mechelynck wrote:
>>
>>> Trying to compile the latest vim 7.3a (74c8bba1d9e8) I get the following
>>> error (the empty line after the command-line is an artefact to make it
>>> more readable):
>>>
>>> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
>>> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
>>> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
>>> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
>>> -I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
>>> -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
>>> -I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
>>> -I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
>>> -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
>>> -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
>>> -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
>>> -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
>>> -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
>>> -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
>>> -I/usr/include/pango-1.0 -I/usr/include/gail-1.0
>>> -I/usr/include/freetype2 -I/usr/include/atk-1.0
>>> -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
>>> -I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
>>> -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
>>> -DDEBUGGING  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>>> -I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
>>> -I/usr/include/python2.6 -pthread -I/usr/include
>>> -D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux
>>> -DRUBY_VERSION=18  -o objects/if_perl.o auto/if_perl.c
>>>
>>> In file included from /usr/include/netinet/in.h:24,
>>>                   from
>>> /usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE/perl.h:1123,
>>>                   from ./vim.h:2074,
>>>                   from if_perl.xs:16:
>>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
>>> /usr/include/stdint.h:52: error: two or more data types in declaration
>>> specifiers
>>> make: *** [objects/if_perl.o] Error 1
>>>
>>>
>>> I did what research I could and found the following:
>>>
>>> src/if_perl.xs:16|#include "vim.h"
>>>
>>> src/vim.h:2074|#include <perl.h>
>>>
>>> .../perl.h:1122|#ifdef I_NETINET_IN
>>> .../perl.h:1123|#   include <netinet/in.h>
>>> .../perl.h:1124|#endif
>>>
>>> /usr/include/netinet/in.h:24|#include <stdint.h>
>>>
>>> /usr/include/stdint.h:31|#ifndef __uint32_t_defined
>>> /usr/include/stdint.h:32|typedef unsigned int         uint32_t;
>>> /usr/include/stdint.h:33|# define __uint32_t_defined
>>>
>>> Looks like the new encryption subsystem should have obeyed :help
>>> style-names, as follows:
>>>
>>> <quote>
>>> Typedef'ed names should end in "_T": >
>>>      typedef int some_T;
>>> </quote>
>>
>> Then we could not use the autoconf check, it always defines uint32_t.
>>
>> I'll undefine uint32_t in vim.h, like it's done for netbeans.
>
>
> The same kind of error still happens when compiling if_python.c:
>
> In file included from /usr/local/include/python2.6/pyport.h:7,
>                 from /usr/local/include/python2.6/Python.h:58,
>                 from if_python.c:49:
> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
> /usr/include/stdint.h:52: error: two or more data types in declaration
> specifiers
>
>
> Shouldn't we include <stdint.h> (introduced in c99) rather than defining
> int32_t when stdint.h is available?  With something more or less like...
>
> #ifdef HAVE_STDINT_H
> #include <stdint.h>
> #else
> /* Define to `unsigned int' or other type that is 32 bit.  */
> #define uint32_t unsigned int
> #endif

That's what the Autoconf macro is supposed to do:

  If stdint.h or inttypes.h does not define the type uint32_t, define
  uint32_t to an unsigned integer type that is exactly 32 bits wide, if
  such a type exists.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Dominique Pellé
On Tue, May 18, 2010 at 9:46 PM, James Vega <[hidden email]> wrote:

> 2010/5/18 Dominique Pellé <[hidden email]>:
>> On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar <[hidden email]> wrote:
>>>
>>> Tony Mechelynck wrote:
>>>
>>>> Trying to compile the latest vim 7.3a (74c8bba1d9e8) I get the following
>>>> error (the empty line after the command-line is an artefact to make it
>>>> more readable):
>>>>
>>>> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
>>>> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
>>>> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
>>>> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
>>>> -I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
>>>> -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
>>>> -I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
>>>> -I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
>>>> -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
>>>> -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
>>>> -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
>>>> -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
>>>> -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
>>>> -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
>>>> -I/usr/include/pango-1.0 -I/usr/include/gail-1.0
>>>> -I/usr/include/freetype2 -I/usr/include/atk-1.0
>>>> -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
>>>> -I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
>>>> -D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
>>>> -DDEBUGGING  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>>>> -I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
>>>> -I/usr/include/python2.6 -pthread -I/usr/include
>>>> -D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux
>>>> -DRUBY_VERSION=18  -o objects/if_perl.o auto/if_perl.c
>>>>
>>>> In file included from /usr/include/netinet/in.h:24,
>>>>                   from
>>>> /usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE/perl.h:1123,
>>>>                   from ./vim.h:2074,
>>>>                   from if_perl.xs:16:
>>>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
>>>> /usr/include/stdint.h:52: error: two or more data types in declaration
>>>> specifiers
>>>> make: *** [objects/if_perl.o] Error 1
>>>>
>>>>
>>>> I did what research I could and found the following:
>>>>
>>>> src/if_perl.xs:16|#include "vim.h"
>>>>
>>>> src/vim.h:2074|#include <perl.h>
>>>>
>>>> .../perl.h:1122|#ifdef I_NETINET_IN
>>>> .../perl.h:1123|#   include <netinet/in.h>
>>>> .../perl.h:1124|#endif
>>>>
>>>> /usr/include/netinet/in.h:24|#include <stdint.h>
>>>>
>>>> /usr/include/stdint.h:31|#ifndef __uint32_t_defined
>>>> /usr/include/stdint.h:32|typedef unsigned int         uint32_t;
>>>> /usr/include/stdint.h:33|# define __uint32_t_defined
>>>>
>>>> Looks like the new encryption subsystem should have obeyed :help
>>>> style-names, as follows:
>>>>
>>>> <quote>
>>>> Typedef'ed names should end in "_T": >
>>>>      typedef int some_T;
>>>> </quote>
>>>
>>> Then we could not use the autoconf check, it always defines uint32_t.
>>>
>>> I'll undefine uint32_t in vim.h, like it's done for netbeans.
>>
>>
>> The same kind of error still happens when compiling if_python.c:
>>
>> In file included from /usr/local/include/python2.6/pyport.h:7,
>>                 from /usr/local/include/python2.6/Python.h:58,
>>                 from if_python.c:49:
>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
>> /usr/include/stdint.h:52: error: two or more data types in declaration
>> specifiers
>>
>>
>> Shouldn't we include <stdint.h> (introduced in c99) rather than defining
>> int32_t when stdint.h is available?  With something more or less like...
>>
>> #ifdef HAVE_STDINT_H
>> #include <stdint.h>
>> #else
>> /* Define to `unsigned int' or other type that is 32 bit.  */
>> #define uint32_t unsigned int
>> #endif
>
> That's what the Autoconf macro is supposed to do:
>
>  If stdint.h or inttypes.h does not define the type uint32_t, define
>  uint32_t to an unsigned integer type that is exactly 32 bits wide, if
>  such a type exists.

Something is wrong then.  I'm using gcc-4.4.1 (Ubuntu-9.10)
which of course has <stdint.h>.  Yet file vim/src/auto/config.h
(generated by configure) redefines uint32_t:

vim/src/auto/config.h:
....
/* Define to `unsigned int' or other type that is 32 bit.  */
#define uint32_t unsigned int
...

Since <stdint.h> exists on my system, I don't think config.h
should re-define it.

-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

James Vega-3
2010/5/18 Dominique Pellé <[hidden email]>:

> On Tue, May 18, 2010 at 9:46 PM, James Vega <[hidden email]> wrote:
>> 2010/5/18 Dominique Pellé <[hidden email]>:
>>> On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar <[hidden email]> wrote:
>>>>
>>>> Then we could not use the autoconf check, it always defines uint32_t.
>>>>
>>>> I'll undefine uint32_t in vim.h, like it's done for netbeans.
>>>
>>>
>>> The same kind of error still happens when compiling if_python.c:
>>>
>>> In file included from /usr/local/include/python2.6/pyport.h:7,
>>>                 from /usr/local/include/python2.6/Python.h:58,
>>>                 from if_python.c:49:
>>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
>>> /usr/include/stdint.h:52: error: two or more data types in declaration
>>> specifiers
>>>
>>>
>>> Shouldn't we include <stdint.h> (introduced in c99) rather than defining
>>> int32_t when stdint.h is available?  With something more or less like...
>>>
>>> #ifdef HAVE_STDINT_H
>>> #include <stdint.h>
>>> #else
>>> /* Define to `unsigned int' or other type that is 32 bit.  */
>>> #define uint32_t unsigned int
>>> #endif
>>
>> That's what the Autoconf macro is supposed to do:
>>
>>  If stdint.h or inttypes.h does not define the type uint32_t, define
>>  uint32_t to an unsigned integer type that is exactly 32 bits wide, if
>>  such a type exists.
>
> Something is wrong then.  I'm using gcc-4.4.1 (Ubuntu-9.10)
> which of course has <stdint.h>.  Yet file vim/src/auto/config.h
> (generated by configure) redefines uint32_t:
>
> vim/src/auto/config.h:
> ....
> /* Define to `unsigned int' or other type that is 32 bit.  */
> #define uint32_t unsigned int
> ...
Ah, the issue is that Vim's configure script isn't checking for stdint.h
or inttypes.h.  Attached patch fixes this and should remove the need for
the other workarounds Bram added.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

types.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

James Vega-3
On Tue, May 18, 2010 at 4:37 PM, James Vega <[hidden email]> wrote:

> 2010/5/18 Dominique Pellé <[hidden email]>:
>> On Tue, May 18, 2010 at 9:46 PM, James Vega <[hidden email]> wrote:
>>> 2010/5/18 Dominique Pellé <[hidden email]>:
>>>> On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar <[hidden email]> wrote:
>>>>>
>>>>> Then we could not use the autoconf check, it always defines uint32_t.
>>>>>
>>>>> I'll undefine uint32_t in vim.h, like it's done for netbeans.
>>>>
>>>>
>>>> The same kind of error still happens when compiling if_python.c:
>>>>
>>>> In file included from /usr/local/include/python2.6/pyport.h:7,
>>>>                 from /usr/local/include/python2.6/Python.h:58,
>>>>                 from if_python.c:49:
>>>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
>>>> /usr/include/stdint.h:52: error: two or more data types in declaration
>>>> specifiers
>>>>
>>>>
>>>> Shouldn't we include <stdint.h> (introduced in c99) rather than defining
>>>> int32_t when stdint.h is available?  With something more or less like...
>>>>
>>>> #ifdef HAVE_STDINT_H
>>>> #include <stdint.h>
>>>> #else
>>>> /* Define to `unsigned int' or other type that is 32 bit.  */
>>>> #define uint32_t unsigned int
>>>> #endif
>>>
>>> That's what the Autoconf macro is supposed to do:
>>>
>>>  If stdint.h or inttypes.h does not define the type uint32_t, define
>>>  uint32_t to an unsigned integer type that is exactly 32 bits wide, if
>>>  such a type exists.
>>
>> Something is wrong then.  I'm using gcc-4.4.1 (Ubuntu-9.10)
>> which of course has <stdint.h>.  Yet file vim/src/auto/config.h
>> (generated by configure) redefines uint32_t:
>>
>> vim/src/auto/config.h:
>> ....
>> /* Define to `unsigned int' or other type that is 32 bit.  */
>> #define uint32_t unsigned int
>> ...
>
> Ah, the issue is that Vim's configure script isn't checking for stdint.h
> or inttypes.h.  Attached patch fixes this and should remove the need for
> the other workarounds Bram added.
Forgot to include vim.h in the patch.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

types.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Bram Moolenaar
In reply to this post by James Vega-3

James Vega wrote:

> 2010/5/18 Dominique Pellé <[hidden email]>:
> > On Tue, May 18, 2010 at 9:46 PM, James Vega <[hidden email]> wrote:
> >> 2010/5/18 Dominique Pellé <[hidden email]>:
> >>> On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar <[hidden email]> wrote:
> >>>>
> >>>> Then we could not use the autoconf check, it always defines uint32_t.
> >>>>
> >>>> I'll undefine uint32_t in vim.h, like it's done for netbeans.
> >>>
> >>>
> >>> The same kind of error still happens when compiling if_python.c:
> >>>
> >>> In file included from /usr/local/include/python2.6/pyport.h:7,
> >>>                 from /usr/local/include/python2.6/Python.h:58,
> >>>                 from if_python.c:49:
> >>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
> >>> /usr/include/stdint.h:52: error: two or more data types in declaration
> >>> specifiers
> >>>
> >>>
> >>> Shouldn't we include <stdint.h> (introduced in c99) rather than defining
> >>> int32_t when stdint.h is available?  With something more or less like...
> >>>
> >>> #ifdef HAVE_STDINT_H
> >>> #include <stdint.h>
> >>> #else
> >>> /* Define to `unsigned int' or other type that is 32 bit.  */
> >>> #define uint32_t unsigned int
> >>> #endif
> >>
> >> That's what the Autoconf macro is supposed to do:
> >>
> >>  If stdint.h or inttypes.h does not define the type uint32_t, define
> >>  uint32_t to an unsigned integer type that is exactly 32 bits wide, if
> >>  such a type exists.
> >
> > Something is wrong then.  I'm using gcc-4.4.1 (Ubuntu-9.10)
> > which of course has <stdint.h>.  Yet file vim/src/auto/config.h
> > (generated by configure) redefines uint32_t:
> >
> > vim/src/auto/config.h:
> > ....
> > /* Define to `unsigned int' or other type that is 32 bit.  */
> > #define uint32_t unsigned int
> > ...
>
> Ah, the issue is that Vim's configure script isn't checking for stdint.h
> or inttypes.h.  Attached patch fixes this and should remove the need for
> the other workarounds Bram added.

These include files also define a bunch of other things.  Are we sure
these won't cause new problems?

Also, how do we know the uint32_t that stdint.h defines is correct?
autoconf needs to verify that.  Well, we could write a test for it.

--
hundred-and-one symptoms of being an internet addict:
71. You wonder how people walk

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Bram Moolenaar
In reply to this post by Dominique Pellé

Dominique Pelle wrote:

> > Then we could not use the autoconf check, it always defines uint32_t.
> >
> > I'll undefine uint32_t in vim.h, like it's done for netbeans.
>
>
> The same kind of error still happens when compiling if_python.c:
>
> In file included from /usr/local/include/python2.6/pyport.h:7,
>                  from /usr/local/include/python2.6/Python.h:58,
>                  from if_python.c:49:
> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
> /usr/include/stdint.h:52: error: two or more data types in declaration
> specifiers
>
>
> Shouldn't we include <stdint.h> (introduced in c99) rather than defining
> int32_t when stdint.h is available?  With something more or less like...
>
> #ifdef HAVE_STDINT_H
> #include <stdint.h>
> #else
> /* Define to `unsigned int' or other type that is 32 bit.  */
> #define uint32_t unsigned int
> #endif

stdint.h is a C99 thing.  I would rather avoid using C99 features.
Unfortunately, it appears it gets dragged in anyway indirectly.

We can't #define uint32_t directly, the sizeof(int) is undefined.

Please try the current version, hopefully this works for everyone.

--
hundred-and-one symptoms of being an internet addict:
70. ISDN lines are added to your house on a hourly basis

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Tony Mechelynck
On 18/05/10 22:59, Bram Moolenaar wrote:

>
> Dominique Pelle wrote:
>
>>> Then we could not use the autoconf check, it always defines uint32_t.
>>>
>>> I'll undefine uint32_t in vim.h, like it's done for netbeans.
>>
>>
>> The same kind of error still happens when compiling if_python.c:
>>
>> In file included from /usr/local/include/python2.6/pyport.h:7,
>>                   from /usr/local/include/python2.6/Python.h:58,
>>                   from if_python.c:49:
>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
>> /usr/include/stdint.h:52: error: two or more data types in declaration
>> specifiers
>>
>>
>> Shouldn't we include<stdint.h>  (introduced in c99) rather than defining
>> int32_t when stdint.h is available?  With something more or less like...
>>
>> #ifdef HAVE_STDINT_H
>> #include<stdint.h>
>> #else
>> /* Define to `unsigned int' or other type that is 32 bit.  */
>> #define uint32_t unsigned int
>> #endif
>
> stdint.h is a C99 thing.  I would rather avoid using C99 features.
> Unfortunately, it appears it gets dragged in anyway indirectly.
>
> We can't #define uint32_t directly, the sizeof(int) is undefined.
>
> Please try the current version, hopefully this works for everyone.
>

Works for me with the following configuration

export CONF_OPT_GUI='--enable-gnome-check'
export CONF_OPT_PERL='--enable-perlinterp'
export CONF_OPT_PYTHON='--enable-pythoninterp'
export CONF_OPT_TCL='--enable-tclinterp'
export CONF_OPT_RUBY='--enable-rubyinterp'
export CONF_OPT_MZSCHEME='--disable-mzschemeinterp'
export CONF_OPT_CSCOPE='--enable-cscope'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_OPT_COMPBY='"--with-compiledby=[hidden email]"'

and a feature.h change for -tag_old_static +xterm_save ; producing the
following :version:

VIM - Vi IMproved 7.3 BETA (2010 May 15, compiled May 19 2010 02:29:27)
Extra patches: Extra float functions (Bill McCarthy)
Compiled by [hidden email]
Huge version with GTK2-GNOME GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui
+diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search
+farsi +file_in_path +find_in_path +float +folding -footer +fork()
+gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap
+libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
+modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm
+mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte +multi_lang
-mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript
+printer +profile +python +quickfix +reltime +rightleft +ruby
+scrollbind +signs +smartindent -sniff +startuptime +statusline
-sun_workshop
+syntax +tag_binary -tag_old_static -tag_any_white +tcl +terminfo
+termresponse +textobjects +title +toolbar +user_commands +vertsplit
+virtualedit +visual +visualextra +viminfo +vreplace +wildignore
+wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact
+xterm_clipboard +xterm_save
    system vimrc file: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
       user exrc file: "$HOME/.exrc"
   system gvimrc file: "$VIM/gvimrc"
     user gvimrc file: "$HOME/.gvimrc"
     system menu file: "$VIMRUNTIME/menu.vim"
   fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12   -DORBIT2=1 -pthread
-I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
-I/usr/include/gconf/2 -I/usr/include/gnome-keyring-1
-I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
-I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2
-I/usr/include/pango-1.0 -I/usr/include/gail-1.0
-I/usr/include/freetype2 -I/usr/include/atk-1.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/libpng12     -O2 -fno-strength-reduce -Wall
-D_FORTIFY_SOURCE=1    -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
-DDEBUGGING  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
-I/usr/include/python2.6 -pthread -I/usr/include
-D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i586-linux -DRUBY_VERSION=18
Linking: gcc   -L.  -rdynamic -Wl,-export-dynamic  -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE  -L.
-rdynamic -Wl,-export-dynamic  -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
-L/usr/local/lib -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
-lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lglib-2.0     -lgnomeui-2 -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2
-lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lart_lgpl_2
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
-lfontconfig -lgconf-2 -lgthread-2.0 -lrt -lgmodule-2.0 -lgobject-2.0
-lglib-2.0   -lXt -lncurses -lacl -lgpm   -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
-L/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -lperl -lutil -lc
-L/usr/lib/python2.6/config -lpython2.6 -lutil -Xlinker -export-dynamic
-L/usr/lib -ltcl8.5 -lieee -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby -lm

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Dominique Pellé
In reply to this post by Bram Moolenaar
Bram Moolenaar wrote:

> James Vega wrote:
>
>> 2010/5/18 Dominique Pellé <[hidden email]>:
>> > On Tue, May 18, 2010 at 9:46 PM, James Vega <[hidden email]> wrote:
>> >> 2010/5/18 Dominique Pellé <[hidden email]>:
>> >>> On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar <[hidden email]> wrote:
>> >>>>
>> >>>> Then we could not use the autoconf check, it always defines uint32_t.
>> >>>>
>> >>>> I'll undefine uint32_t in vim.h, like it's done for netbeans.
>> >>>
>> >>>
>> >>> The same kind of error still happens when compiling if_python.c:
>> >>>
>> >>> In file included from /usr/local/include/python2.6/pyport.h:7,
>> >>>                 from /usr/local/include/python2.6/Python.h:58,
>> >>>                 from if_python.c:49:
>> >>> /usr/include/stdint.h:52: error: duplicate ‘unsigned’
>> >>> /usr/include/stdint.h:52: error: two or more data types in declaration
>> >>> specifiers
>> >>>
>> >>>
>> >>> Shouldn't we include <stdint.h> (introduced in c99) rather than defining
>> >>> int32_t when stdint.h is available?  With something more or less like...
>> >>>
>> >>> #ifdef HAVE_STDINT_H
>> >>> #include <stdint.h>
>> >>> #else
>> >>> /* Define to `unsigned int' or other type that is 32 bit.  */
>> >>> #define uint32_t unsigned int
>> >>> #endif
>> >>
>> >> That's what the Autoconf macro is supposed to do:
>> >>
>> >>  If stdint.h or inttypes.h does not define the type uint32_t, define
>> >>  uint32_t to an unsigned integer type that is exactly 32 bits wide, if
>> >>  such a type exists.
>> >
>> > Something is wrong then.  I'm using gcc-4.4.1 (Ubuntu-9.10)
>> > which of course has <stdint.h>.  Yet file vim/src/auto/config.h
>> > (generated by configure) redefines uint32_t:
>> >
>> > vim/src/auto/config.h:
>> > ....
>> > /* Define to `unsigned int' or other type that is 32 bit.  */
>> > #define uint32_t unsigned int
>> > ...
>>
>> Ah, the issue is that Vim's configure script isn't checking for stdint.h
>> or inttypes.h.  Attached patch fixes this and should remove the need for
>> the other workarounds Bram added.
>
> These include files also define a bunch of other things.  Are we sure
> these won't cause new problems?
>
> Also, how do we know the uint32_t that stdint.h defines is correct?
> autoconf needs to verify that.  Well, we could write a test for it.

Just to confirm that the latest version (changeset:2187:e741fe7a0547)
works for me on Ubuntu-9.10 with Vim huge GTK2 GNOME GUI
+mzscheme +perl +python +ruby +tcl.

Even if Vim never includes <stdint.h>, some system header files may
perhaps include it? So I'm wondering how safe it is to undefine uint32_t
in vim.h. I quite like the latest patch proposed by James Vega.

Regards
-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

Bram Moolenaar
In reply to this post by James Vega-3

James Vega wrote:

> >> (generated by configure) redefines uint32_t:
> >>
> >> vim/src/auto/config.h:
> >> ....
> >> /* Define to `unsigned int' or other type that is 32 bit.  */
> >> #define uint32_t unsigned int
> >> ...
> >
> > Ah, the issue is that Vim's configure script isn't checking for stdint.h
> > or inttypes.h.  Attached patch fixes this and should remove the need for
> > the other workarounds Bram added.
>
> Forgot to include vim.h in the patch.

I have included this and defined UINT32_T to uint32_t.  Hopefully that
avoids all the problems reported.

I also added an extra check for uint32_t, both in configure and before
using blowfish.  I hope that someone can make this work for cross
compiling.

--
hundred-and-one symptoms of being an internet addict:
78. You find yourself dialing IP numbers on the phone.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Problem with vim7.3a and Perl : in <stdint.h>, collision with uint32_t defined elsewhere without setting __uint32_t_defined

tux.
Bram Moolenaar schrob am 19.05.2010 22:11:
I have included this and defined UINT32_T to uint32_t.  Hopefully that
avoids all the problems reported.

Confirmed, compiling on Win32 obviously works again. :)

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php