Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
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
Re: Problem with vim7.3a and Perl (OOPS)
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
Re: Problem with vim7.3a and Perl (OOPS)
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
Patch to make link.sh output a bit less scary.
Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. 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 diff -r 74c8bba1d9e8 src/link.sh --- a/src/link.sh Mon May 17 22:07:47 2010 +0200 +++ b/src/link.sh Tue May 18 05:15:16 2010 -0400 @@ -46,7 +46,7 @@ while test -n $cont; do if grep l$libname linkit.sh /dev/null; then if test ! -f link1.sed; then -echo link.sh: OK, linking works, let's try removing a few libraries. +echo link.sh: OK, linking works, let's try delinking a few libraries. echo link.sh: See auto/link.log for details. rm -f auto/link.log fi @@ -55,12 +55,12 @@ sed -f link1.sed linkit2.sh linkit.sh # keep the last -lm if test $libname != m || grep lm linkit.sh /dev/null; then -echo link.sh: Trying to remove the $libname library... +echo link.sh: Trying to delink the $libname library... cat linkit.sh auto/link.log # Redirect this link output, it may contain error messages which # should be ignored. if sh linkit.sh auto/link.log 21; then - echo link.sh: We don't need the $libname library! + echo link.sh: We don't need the $libname library for vim! cat link1.sed auto/link.sed rm -f auto/pathdef.c else @@ -82,7 +82,7 @@ $MAKE objects/pathdef.o fi if test ! -f link1.sed; then - echo link.sh: Linked fine, no libraries can be removed + echo link.sh: Linked fine, no libraries can be delinked touch link3.sed fi else @@ -94,12 +94,12 @@ # Now do the real linking. # if test -s auto/link.sed; then - echo link.sh: Using auto/link.sed file to remove a few libraries + echo link.sh: Using auto/link.sed file to delink a few libraries sed -f auto/link.sed link.cmd linkit.sh cat linkit.sh if sh linkit.sh; then exit_value=0 -echo link.sh: Linked fine with a few libraries removed +echo link.sh: Linked fine with a few libraries delinked else exit_value=$? echo link.sh: Linking failed, making auto/link.sed empty and trying again
Re: Problem with vim7.3a and Perl
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
Re: Compiling vim 7.3 failed on Win XP with mingw
On 18/05/2010 03:43 a.m., Bram Moolenaar wrote: Cesar Romani wrote: I got following error: gobjZ/ex_docmd.o:ex_docmd.c:(.text+0x1116c): undefined reference to `blowfish_self_test' gobjZ/fileio.o:fileio.c:(.text+0x704f): undefined reference to `blowfish_self_test' gobjZ/fileio.o:fileio.c:(.text+0x7f18): undefined reference to `bf_key_init' gobjZ/fileio.o:fileio.c:(.text+0x7f2b): undefined reference to `bf_ofb_init' gobjZ/fileio.o:fileio.c:(.text+0xc1f9): undefined reference to `sha2_seed' gobjZ/fileio.o:fileio.c:(.text+0xc207): undefined reference to `bf_ofb_init' gobjZ/fileio.o:fileio.c:(.text+0xc216): undefined reference to `bf_key_init' gobjZ/main.o:main.c:(.text+0x3e21): undefined reference to `blowfish_self_test' gobjZ/misc2.o:misc2.c:(.text+0x2ce3): undefined reference to `bf_ofb_update' gobjZ/misc2.o:misc2.c:(.text+0x2bbe): undefined reference to `bf_ranbyte' gobjZ/misc2.o:misc2.c:(.text+0x2bf5): undefined reference to `bf_ofb_update' gobjZ/option.o:option.c:(.text+0x54ac): undefined reference to `blowfish_self_test' collect2: ld returned 1 exit status make: *** [gvim.exe] Error 1 Many thanks in advance I suspect the blowfish.c and sha256.c files are missing from the Makefile. Which Makefile were you using? I'm using Make_ming.mak and it also misses from Make_cyg.mak Regards -- Cesar -- 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
Re: Compiling vim 7.3 failed on Win XP with mingw
On 18/05/2010 07:37 a.m., Cesar Romani wrote:
On 18/05/2010 03:43 a.m., Bram Moolenaar wrote:
Cesar Romani wrote:
I got following error:
gobjZ/ex_docmd.o:ex_docmd.c:(.text+0x1116c): undefined reference to
`blowfish_self_test'
gobjZ/fileio.o:fileio.c:(.text+0x704f): undefined reference to
`blowfish_self_test'
[...]
gobjZ/option.o:option.c:(.text+0x54ac): undefined reference to
`blowfish_self_test'
collect2: ld returned 1 exit status
make: *** [gvim.exe] Error 1
Many thanks in advance
I suspect the blowfish.c and sha256.c files are missing from the
Makefile. Which Makefile were you using?
I'm using Make_ming.mak and it also misses from Make_cyg.mak
If I include blowfish.c and sha256.c I get:
...
blowfish.c:24: error: syntax error before uint32_t
blowfish.c:26: error: syntax error before '}' token
blowfish.c:39: error: syntax error before '*' token
blowfish.c:41: error: syntax error before ipa
blowfish.c:45: error: syntax error before pax
blowfish.c:46: error: syntax error before ipa
blowfish.c:55: error: syntax error before sbx
blowfish.c:56: error: syntax error before sbi
blowfish.c:334: error: syntax error before uint32_t
blowfish.c:335: error: syntax error before '*' token
blowfish.c:336: error: syntax error before '{' token
blowfish.c:342: error: `xl' undeclared here (not in a function)
blowfish.c:342: error: `xr' undeclared here (not in a function)
blowfish.c:342: error: initializer element is not constant
blowfish.c:343: error: initializer element is not constant
blowfish.c:343: error: initializer element is not constant
blowfish.c:344: error: syntax error before '}' token
blowfish.c: In function `bf_e_cblock':
blowfish.c:375: error: syntax error before bk
blowfish.c:376: error: `bk' undeclared (first use in this function)
blowfish.c:376: error: (Each undeclared identifier is reported only once
blowfish.c:376: error: for each function it appears in.)
blowfish.c: In function `bf_key_init':
blowfish.c:404: error: `uint32_t' undeclared (first use in this function)
blowfish.c:404: error: syntax error before val
blowfish.c:420: error: `val' undeclared (first use in this function)
blowfish.c:426: error: `data_l' undeclared (first use in this function)
blowfish.c:426: error: `data_r' undeclared (first use in this function)
blowfish.c: At top level:
blowfish.c:450: error: syntax error before uint32_t
blowfish.c:451: error: syntax error before sbi
blowfish.c:452: error: syntax error before val
blowfish.c:457: error: syntax error before for
blowfish.c:470: error: syntax error before uint32_t
blowfish.c:475: error: syntax error before bf_test_data
blowfish.c: In function `bf_self_test':
blowfish.c:493: error: syntax error before bk
blowfish.c:501: error: request for member `password' in something not a
structure or union
blowfish.c:502: error: request for member `keysum' in something not a
structure or union
blowfish.c:506: error: `bk' undeclared (first use in this function)
blowfish.c:506: error: request for member `plaintxt' in something not a
structure or union
blowfish.c:508: error: request for member `cryptxt' in something not a
structure or union
blowfish.c:510: error: request for member `badcryptxt' in something not
a structure or union
make: *** [gobjZ/blowfish.o] Error 1
Regards
--
Cesar
--
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
Re: Patch to make link.sh output a bit less scary.
On 18/05/10 11:24, Jeff Horelick wrote: Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. 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 Now that you mention it, the word remove could be ambiguous (though after OK link works I never thought that the removal could be other than from the link command-line), but delink sounds barbarous to me. What about (in pseudo-printf notation): OK, linking works, let's try and simplify the command-line Trying not to use the %s library This Vim build doesn't need the %s library This Vim build DOES need the %s library Linked fine, the link command-line cannot be simplified Using auto/link.sed to simplify the link command-line Linked fine using some fewer libraries ? Best regards, Tony. -- Simon's Law: Everything put together falls apart sooner or later. -- 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
Re: Patch to make link.sh output a bit less scary.
On Tue, May 18, 2010 at 11:04 AM, Cesar Romani wrote: On 18/05/2010 04:24 a.m., Jeff Horelick wrote: Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. I'd use unlinking instead of delinking. I'd say Not linking in libXt or Removing libXt from libraries or Going to link without libXt. ~Matt -- 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
Re: Patch to make link.sh output a bit less scary.
Cesar Romani wrote: On 18/05/2010 04:24 a.m., Jeff Horelick wrote: Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. I'd use unlinking instead of delinking. How about this message instead: link.sh: Trying to link without libXt -- 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
Re: Patch to make link.sh output a bit less scary.
On 2010-05-18, Matt Wozniski wrote: On Tue, May 18, 2010 at 11:04 AM, Cesar Romani wrote: On 18/05/2010 04:24 a.m., Jeff Horelick wrote: Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. I'd use unlinking instead of delinking. I'd say Not linking in libXt or Removing libXt from libraries or Going to link without libXt. I was also going to suggest not linking. Definitely not unlinking. Think about that. Regards, Gary -- 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
[patch] g8 displays 0a instead of 00 on NUL character
Hi
When pressing g8 in normal mode on the NUL character 00,
Vim-7.3 (and older) displays 0a. It should display 00. The :ascii
Ex command correctly displays 00.
Steps to reproduce:
1) Create a file with NUL char in it:
$ perl -e 'print chr(0)' test.txt
2) Run:
$ vim -u NONE -c :set display=uhex -c :norm g8 test.txt
3) Observe that Vim displays 0a at the bottom of the screen instead
of the expected 00.
Attached patch fixes 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
diff -r 74c8bba1d9e8 src/mbyte.c
--- a/src/mbyte.c Mon May 17 22:07:47 2010 +0200
+++ b/src/mbyte.c Tue May 18 20:23:55 2010 +0200
@@ -3150,6 +3150,7 @@
int len;
int rlen = 0;
char_u *line;
+char_u c;
int clen;
int i;
@@ -3176,7 +3177,8 @@
}
clen = utf_ptr2len(line + i);
}
- sprintf((char *)IObuff + rlen, %02x , line[i]);
+ c = (line[i] == NL) ? NUL : line[i]; /* NUL is stored as NL */
+ sprintf((char *)IObuff + rlen, %02x , c);
--clen;
rlen += (int)STRLEN(IObuff + rlen);
if (rlen IOSIZE - 20)
@@ -4871,7 +4873,7 @@
*
* An alternative approach would be to destroy the IM context and
* recreate it. But that means loading/unloading the IM module on
- * every mode switch, which causes a quite noticable delay even on
+ * every mode switch, which causes a quite noticeable delay even on
* my rather fast box...
* *
* Moreover, there are some XIM which cannot respond to
@@ -5179,7 +5181,7 @@
static void
im_xim_send_event_imactivate()
{
-/* Force turn on preedit state by symulate keypress event.
+/* Force turn on preedit state by simulating keypress event.
* Keycode and state is specified by 'imactivatekey'.
*/
XKeyEvent ev;
@@ -5256,7 +5258,7 @@
{
/* Force turn off preedit state. With some IM
* implementations, we cannot turn off preedit state by
- * symulate keypress event. It is why using such a method
+ * simulating keypress event. It is why using such a method
* that destroy old IC (input context), and create new one.
* When create new IC, its preedit state is usually off.
*/
@@ -5272,14 +5274,14 @@
else
{
/* First, force destroy old IC, and create new one. It
- * symulates turning off preedit state.
+ * simulates turning off preedit state.
*/
xim_set_focus(FALSE);
gdk_ic_destroy(xic);
xim_init();
xim_can_preediting = FALSE;
- /* 2nd, when requested to activate IM, symulate this by sending
+ /* 2nd, when requested to activate IM, simulate this by sending
* the event.
*/
if (active)
@@ -5334,7 +5336,7 @@
* couldn't switch state of XIM preediting. This is reason why these
* codes are commented out.
*/
- /* First, force destroy old IC, and create new one. It symulates
+ /* First, force destroy old IC, and create new one. It simulates
* turning off preedit state.
*/
xim_set_focus(FALSE);
@@ -5342,7 +5344,7 @@
xic = NULL;
xim_init();
- /* 2nd, when requested to activate IM, symulate this by sending the
+ /* 2nd, when requested to activate IM, simulate this by sending the
* event.
*/
if (active)
Re: Patch to make link.sh output a bit less scary.
Gary Johnson wrote: On 2010-05-18, Matt Wozniski wrote: On Tue, May 18, 2010 at 11:04 AM, Cesar Romani wrote: On 18/05/2010 04:24 a.m., Jeff Horelick wrote: Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. I'd use unlinking instead of delinking. I'd say Not linking in libXt or Removing libXt from libraries or Going to link without libXt. I was also going to suggest not linking. Definitely not unlinking. Think about that. How about link.sh: Vim doesn't need libXt, so you don't either! Am uninstalling it now ... ... ... Done! (just kidding!) :) Regards, Chip Campbell -- 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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
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 -- b...@moolenaar.net -- 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
Re: Compiling vim 7.3 failed on Win XP with mingw
Cesar Romani wrote: On 18/05/2010 03:43 a.m., Bram Moolenaar wrote: Cesar Romani wrote: I got following error: gobjZ/ex_docmd.o:ex_docmd.c:(.text+0x1116c): undefined reference to `blowfish_self_test' gobjZ/fileio.o:fileio.c:(.text+0x704f): undefined reference to `blowfish_self_test' gobjZ/fileio.o:fileio.c:(.text+0x7f18): undefined reference to `bf_key_init' gobjZ/fileio.o:fileio.c:(.text+0x7f2b): undefined reference to `bf_ofb_init' gobjZ/fileio.o:fileio.c:(.text+0xc1f9): undefined reference to `sha2_seed' gobjZ/fileio.o:fileio.c:(.text+0xc207): undefined reference to `bf_ofb_init' gobjZ/fileio.o:fileio.c:(.text+0xc216): undefined reference to `bf_key_init' gobjZ/main.o:main.c:(.text+0x3e21): undefined reference to `blowfish_self_test' gobjZ/misc2.o:misc2.c:(.text+0x2ce3): undefined reference to `bf_ofb_update' gobjZ/misc2.o:misc2.c:(.text+0x2bbe): undefined reference to `bf_ranbyte' gobjZ/misc2.o:misc2.c:(.text+0x2bf5): undefined reference to `bf_ofb_update' gobjZ/option.o:option.c:(.text+0x54ac): undefined reference to `blowfish_self_test' collect2: ld returned 1 exit status make: *** [gvim.exe] Error 1 Many thanks in advance I suspect the blowfish.c and sha256.c files are missing from the Makefile. Which Makefile were you using? I'm using Make_ming.mak and it also misses from Make_cyg.mak And a few others, some were only partly adjusted by the patch. I'll go through all of them. -- hundred-and-one symptoms of being an internet addict: 63. You start using smileys in your snail mail. /// Bram Moolenaar -- b...@moolenaar.net -- 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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar b...@moolenaar.net 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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar b...@moolenaar.net 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 james...@jamessan.com -- 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
Re: No 7.3a patchlevels?
Tony Mechelynck, 2010-05-16 18:09: for instance on my local repository there's one additional revision every time I fetch the source (if there is a change in one or more of src/version.c, src/Makefile, src/eval.c or src/feature.h) A few days ago I told you that it has *nothing* to do with your 4 locally modified files. Thanks for listening. I stop trying to help now, you will find it out yourself. But in short: the Automated merge changeset will always be created because, even if there are no changes in your 4 modified files and thus Mercurial doesn't has to merge on file level, it still has to merge on history level. Markus -- 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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
On Tue, May 18, 2010 at 9:46 PM, James Vega james...@jamessan.com wrote: 2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar b...@moolenaar.net 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
Re: Patch to make link.sh output a bit less scary.
Jeff Horelick wrote: Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. Are these the same people that ask for a copy of the internet? Anyway, using omit instead of remove is probably better. I don't know what delinking is. -- hundred-and-one symptoms of being an internet addict: 67. Your hard drive crashes. You haven't logged in for two hours. You start to twitch. You pick up the phone and manually dial your ISP's access number. You try to hum to communicate with the modem. You succeed. /// Bram Moolenaar -- b...@moolenaar.net -- 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
Re: Compiling vim 7.3 failed on Win XP with mingw
Cesar Romani wrote: On 18/05/2010 07:37 a.m., Cesar Romani wrote: On 18/05/2010 03:43 a.m., Bram Moolenaar wrote: Cesar Romani wrote: I got following error: gobjZ/ex_docmd.o:ex_docmd.c:(.text+0x1116c): undefined reference to `blowfish_self_test' gobjZ/fileio.o:fileio.c:(.text+0x704f): undefined reference to `blowfish_self_test' [...] gobjZ/option.o:option.c:(.text+0x54ac): undefined reference to `blowfish_self_test' collect2: ld returned 1 exit status make: *** [gvim.exe] Error 1 Many thanks in advance I suspect the blowfish.c and sha256.c files are missing from the Makefile. Which Makefile were you using? I'm using Make_ming.mak and it also misses from Make_cyg.mak If I include blowfish.c and sha256.c I get: ... blowfish.c:24: error: syntax error before uint32_t blowfish.c:26: error: syntax error before '}' token blowfish.c:39: error: syntax error before '*' token blowfish.c:41: error: syntax error before ipa [...] make: *** [gobjZ/blowfish.o] Error 1 Strange that these compilers don't define uint32_t. I'll add it in vim.h: #if !defined(HAVE_CONFIG_H) !defined(uint32_t) \ (defined(__CYGWIN32__) || defined(__MINGW32__)) /* Assuming that MingW and Cygwin do not typedef uint32_t. */ # define uint32_t unsigned int #endif We can't check for a typedef, otherwise we could solve this in a more generic way. -- hundred-and-one symptoms of being an internet addict: 65. The last time you looked at the clock it was 11:30pm, and in what seems like only a few seconds later, your sister runs past you to catch her 7am school bus. /// Bram Moolenaar -- b...@moolenaar.net -- 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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:46 PM, James Vega james...@jamessan.com wrote: 2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar b...@moolenaar.net 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 james...@jamessan.com -- 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 Description: Binary data
Re: Patch to make link.sh output a bit less scary.
On May 18, 4:29 pm, Bram Moolenaar b...@moolenaar.net wrote: Jeff Horelick wrote: Hey, i've noticed some people saying on IRC and randomly throughout the web in places that the whole: link.sh: We don't need libXt! link.sh: Removing libXt! thing is a bit scary if you're new to compiling vim or compiling stuff on linux in general because you might think its actually going to remove libxt from your whole system. Because of this, I have attached a very simple patch to change the link.sh echos to say delinking instead of removing which sounds quite a bit less scary. Are these the same people that ask for a copy of the internet? Anyway, using omit instead of remove is probably better. I don't know what delinking is. -- hundred-and-one symptoms of being an internet addict: 67. Your hard drive crashes. You haven't logged in for two hours. You start to twitch. You pick up the phone and manually dial your ISP's access number. You try to hum to communicate with the modem. You succeed. /// Bram Moolenaar -- b...@moolenaar.net --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, visithttp://www.vim.org/maillist.php They're also likely the type of people who own the Brooklyn Bridge (does that joke work outside the US?). Omit sounds quite good to me. I used delinking because I was sort of under the impression that it built Vim linking to all these libraries and then link.sh stripped them out, but i could be wrong. -- 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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
On Tue, May 18, 2010 at 4:37 PM, James Vega james...@jamessan.com wrote: 2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:46 PM, James Vega james...@jamessan.com wrote: 2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar b...@moolenaar.net 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 james...@jamessan.com -- 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 Description: Binary data
Re: Patch 7.2.407
Am 23.03.2010 16:27, schrieb Bram Moolenaar: Patch 7.2.407 Problem:When using an expression in :s backslashes in the result are dropped. (Sergey Goldgaber, Christian Brabandt) Solution: Double backslashes. Files: src/regexp.c I found a bug (two lines of text below): abc\ def :s/abc\\\ndef/\=submatch(0)/ result: ab...@def (^@ is one character) BTW: How do you now insert a literal CR or a literal NL? E.g. this worked before: :s/.*/\=abc\\\CRdef/ (or :s/.*/\=abc\\\rdef/ or :s/.*/\='abc\^Mdef'/where ^M was inserted with C-VCR) It now breaks the line. What about backwards compatibility? I had a script dealing with conversion of binary data, it's (most probably) broken now. I also see updates for other scripts due to this patch, e.g. Vimscript #162, auctex.vim, v2.2.1 - v2.2.2 -- Andy -- 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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
James Vega wrote: 2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:46 PM, James Vega james...@jamessan.com wrote: 2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar b...@moolenaar.net 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 -- b...@moolenaar.net -- 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
Re: Compiling vim 7.3 failed on Win XP with mingw
On Tue, May 18, 2010 at 4:29 PM, Bram Moolenaar b...@moolenaar.net wrote: Cesar Romani wrote: On 18/05/2010 07:37 a.m., Cesar Romani wrote: On 18/05/2010 03:43 a.m., Bram Moolenaar wrote: Cesar Romani wrote: I got following error: gobjZ/ex_docmd.o:ex_docmd.c:(.text+0x1116c): undefined reference to `blowfish_self_test' gobjZ/fileio.o:fileio.c:(.text+0x704f): undefined reference to `blowfish_self_test' [...] gobjZ/option.o:option.c:(.text+0x54ac): undefined reference to `blowfish_self_test' collect2: ld returned 1 exit status make: *** [gvim.exe] Error 1 Many thanks in advance I suspect the blowfish.c and sha256.c files are missing from the Makefile. Which Makefile were you using? I'm using Make_ming.mak and it also misses from Make_cyg.mak If I include blowfish.c and sha256.c I get: ... blowfish.c:24: error: syntax error before uint32_t blowfish.c:26: error: syntax error before '}' token blowfish.c:39: error: syntax error before '*' token blowfish.c:41: error: syntax error before ipa [...] make: *** [gobjZ/blowfish.o] Error 1 Strange that these compilers don't define uint32_t. They most likely do define it, but you have to include inttypes.h or stdint.h to get that definition. Vim currently doesn't do that anywhere. The patch I sent in the Problem with vim7.3a and Perl thread includes those header files based on configure checks. Not sure how you want to handle it for non-configure systems. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com -- 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
Vim 7.3a does not compile anymore: blowfish.c, sha256.c broken?
While trying to compile Vim 7.3a from Hg under Windows (which worked fine a few hours ago) with Visual Studio 2008, I receive the following errors: http://pastebin.com/G3XxEsqN Compilation command: nmake -f Make_mvc.mak GUI=yes OLE=yes PERL=C:\Perl DYNAMIC_PERL=yes PYTHON=C:\Programme\Python DYNAMIC_PYTHON=yes SNIFF=yes CSCOPE=yes IME=yes GIME=yes MBYTE=yes FEATURES=huge RUBY=C:\Ruby DYNAMIC_RUBY=yes TCL=C:\tcl DYNAMIC_TCL=yes POSTSCRIPT=yes XPM=..\..\libXpm HTH. -- 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
Re: Patch to make link.sh output a bit less scary.
On 18/05/10 22:42, JD wrote: [...] They're also likely the type of people who own the Brooklyn Bridge (does that joke work outside the US?). I'm Belgian, and I've met it before, so maybe it does. Omit sounds quite good to me. I used delinking because I was sort of under the impression that it built Vim linking to all these libraries and then link.sh stripped them out, but i could be wrong. that's what it does (removing them one at a time from the link command-line then trying to repeat the link without them) but the main objection about delinking was that the word isn't known. Linking without, not using, omitting (i.e. omitting from the link) etc. all are known English terms which any Vim developer from all over the world would be supposed to understand. Best regards, Tony. -- Q: How much money do you give to a 900 foot Jesus? A: As much as he wants. -- 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
RE: New script: SmartTag (resolves ambiguous C++ tags etc)
I couldn't resist:
I used github because it works best and fastest for me:
http://github.com/MarcWeber/SmartTag
I also moved code and renamed SmartTag to SmartTag#SmartTag
When enabling tagfunc by setting to SmartTag or SmartTag#SmartTag should
tjump show only one match as well? This didn't work for me.
The :call SmartTag#SmartTag('goto')
Does not require that feature, does it?
Robert: Do you have a www.vim.org account?
You can use the SVN mirror and use svn diff to create diffs
which youc an send to me. You can also install git.
I could create a SSH account which you can login into to push
changes yourself.
Lech: Do you have a repository location now?
Marc Weber
--
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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
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 includestdint.h (introduced in c99) rather than defining int32_t when stdint.h is available? With something more or less like... #ifdef HAVE_STDINT_H #includestdint.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=antoine.mechely...@gmail.com' 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 antoine.mechely...@gmail.com 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
Re: Compiling vim 7.3 failed on Win XP with mingw
On 18 May 2010 16:29, Bram Moolenaar wrote: Strange that these compilers don't define uint32_t. I'll add it in vim.h: Unfortunately revision 2184 seems to have broken Cygwin compilation with complaints of uint32_t being undefined. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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
Re: Problem with vim7.3a and Perl : in stdint.h, collision with uint32_t defined elsewhere without setting __uint32_t_defined
Bram Moolenaar wrote: James Vega wrote: 2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:46 PM, James Vega james...@jamessan.com wrote: 2010/5/18 Dominique Pellé dominique.pe...@gmail.com: On Tue, May 18, 2010 at 9:06 PM, Bram Moolenaar b...@moolenaar.net 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
