vim 7.3

[Charles Campbell]

Hello,

I just attempted to update my copy of vim 7.2 with:

(date && hg pull -u) 2>&1 |tee -a ../hg-vim.log

I followed that up with a gmake distclean
and ./configure --with-features=huge
--enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp
--enable-gnome-check --enable-cscope

Configure failed with the following message:

checking size of off_t... configure: error: in
`/home/cec/.SW/VIM/Merc/vim/src':
configure: error: cannot compute sizeof (off_t)

Here's some excerpts from config.log: (a centos 5.2 system)

hostname = xorn.gsfc.nasa.gov
uname -m = x86_64
uname -r = 2.6.18-194.3.1.el5
uname -s = Linux
uname -v = #1 SMP Thu May 13 13:08:30 EDT 2010

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch = x86_64
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

...

configure:11492: checking size of off_t
configure:11497: gcc -o conftest -g -O2 -Wl,-E
-Wl,-rpath,/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE
-L/usr/local/lib conftest.c -lm -lncurses -lelf -lnsl -lselinux -lacl
-lattr -lgpm >&5
In file included from /usr/include/inttypes.h:28,
from conftest.c:164:
/usr/include/stdint.h:52: error: duplicate 'unsigned'
/usr/include/stdint.h:52: error: two or more data types in declaration
specifiers
configure:11497: $? = 1
configure: program exited with status 1

Here's an excerpt from /usr/include/stdint.h, starting at line 51:

#ifndef __uint32_t_defined
typedef unsigned int uint32_t;
# define __uint32_t_defined
#endif

Vim 7.3 configured&compiled ok before this pull, and FWIW vim 7.2
configures and builds ok (with patches 1-444).

Regards,
Chip Campbell

[Charles Campbell]

Charles Campbell wrote:
> Hello,
>
> I just attempted to update my copy of vim 7.2 with:
>
> (date && hg pull -u) 2>&1 |tee -a ../hg-vim.log
>

sorry, that should've been "...my copy of vim 7.3 with:..."

Regards,
Chip Campbell

[Charles Campbell]

Charles Campbell wrote:
> Hello,
>
> I just attempted to update my copy of vim 7.2 with:
>
> (date && hg pull -u) 2>&1 |tee -a ../hg-vim.log
>
> I followed that up with a gmake distclean
> and ./configure
> --with-features=huge --enable-gui=gtk2 --enable-perlinterp
> --enable-pythoninterp --enable-gnome-check --enable-cscope
>
> Configure failed with the following message:
>

and it also fails the same way with a plain ./configure

Regards,
Chip Campbell

[James Vega]

On Tue, Jun 22, 2010 at 3:03 PM, Charles Campbell
<Charles.E...@nasa.gov> wrote:
> Configure failed with the following message:
>
> checking size of off_t... configure: error: in
> `/home/cec/.SW/VIM/Merc/vim/src':
> configure: error: cannot compute sizeof (off_t)
>
> Here's some excerpts from config.log: (a centos 5.2 system)

> ...
>
> configure:11492: checking size of off_t
> configure:11497: gcc -o conftest -g -O2 -Wl,-E
> -Wl,-rpath,/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE
> -L/usr/local/lib conftest.c -lm -lncurses -lelf -lnsl -lselinux -lacl
> -lattr -lgpm >&5
> In file included from /usr/include/inttypes.h:28,
> from conftest.c:164:
> /usr/include/stdint.h:52: error: duplicate 'unsigned'
> /usr/include/stdint.h:52: error: two or more data types in declaration
> specifiers
> configure:11497: $? = 1
> configure: program exited with status 1

config.log should also show what the program was that it tried to
compile. Posting that would be useful.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>

[James Vega]

On Tue, Jun 22, 2010 at 3:03 PM, Charles Campbell
<Charles.E...@nasa.gov> wrote:

> Vim 7.3 configured&compiled ok before this pull, and FWIW vim 7.2 configures
> and builds ok (with patches 1-444).

Do you know what revision you were at before you pulled?
configure/configure.in haven't changed the off_t check in almost a
month.

[Charles Campbell]

James Vega wrote:
> On Tue, Jun 22, 2010 at 3:03 PM, Charles Campbell
> <Charles.E...@nasa.gov> wrote:
>
>> Vim 7.3 configured&compiled ok before this pull, and FWIW vim 7.2 configures
>> and builds ok (with patches 1-444).
>>
> Do you know what revision you were at before you pulled?
> configure/configure.in haven't changed the off_t check in almost a
> month.
>

Here's the entry in the log that you requested in the preceding email:

configure:11497: gcc -o conftest -g -O2 -L/usr/local/lib conftest.c

-lm -lncurses -lelf -lnsl -lselinux -lacl -lattr -lgpm >&5

I don't know; however,

vim3 --version yields

VIM - Vi IMproved 7.3 BETA (2010 May 15, compiled May 19 2010 15:09:27)

and hg-log.vim has

Wed May 19 12:31:27 EDT 2010
requesting all changes
adding changesets
adding manifests
adding file changes
added 2188 changesets with 17715 changes to 2453 files (+2 heads)
updating to branch default
2283 files updated, 0 files merged, 0 files removed, 0 files unresolved

so its probably been a month since I did the update. I was out of the
country for awhile.

Regards,
Chip Campbell

[Tony Mechelynck]

In my experience it is dangerous to run configure manually, because
sometimes (when there have been changes in the configure scripts IIUC)
make will itself launch configure while "rebuilding the makefiles". In
some cases this will even result in configure being run twice one after
another in a single make run. If make runs configure and doesn't know
your configure arguments, you'll lose them, or part of them.

My gvim 7.3a (very similar to yours: Linux 32bit Huge +gui_gtk2
+gui_gnome +cscope -mzscheme +perl +python +ruby +tcl) compiles with no
problem from the latest sources as of Tue 22 Jun 06:28:58 2010 +0002
(and auto/config.h defines SIZEOF_OFF_T as 8). I just ran "make
reconfig" to make sure, after checking that auto/configure (which, in my
shadowdir, is a softlink to ../../configure) pointed to something no
older than configure.in etc. See at
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm how I set my
configure arguments in environment variables passed to make, so that
whenever configure is run, even "by surprise" by make, it always gets
the settings I chose.

Currently I compile Vim in a "shadow directory" built by "make shadow"
under the src/ directory and mentioned in .hgignore. I have replaced the
Makefile copy there by a softlink, since my build methods require no
featureset-choice changes to the Makefile. The script to set the
environment variables is in that shadow directory, so after updating the
repository I run the following in another more or less permanent shell
two directory levels down:

(date && source mycfg && make) 2>&1 |tee -a make.log
and if successful
(date && source mycfg && make install) 2>&1 |tee -a make.log

This "make" program is GNU make, and /usr/bin/gmake is here a softlink
to it.)

Now, about where this off_t definition comes from. Running cscope over
the Vim source, I find the following:

1 76 src/os_amiga.h <<off_t>>
typedef long off_t
2 67 src/os_msdos.h <<off_t>>
typedef long off_t
3 62 src_os_win16.h <<off_t>>
typedef long off_t
4 76 /usr/include/sys/stat.h <<off_t>>
typedef __off_t off_t
5 78 /usr/include/sys/stat.h <<off_t>>
typedef __off64_t off_t
6 88 /usr/include/sys/types.h <<off_t>>
typedef __off_t off_t
7 90 /usr/include/sys/types.h <<off_t>>
typedef __off64_t off_t
8 244 /usr/include/unistd.h <<off_t>>
typedef __off_t off_t
9 246 /usr/include/unistd.h <<off_t>>
typedef __off64_t off_t

and I see that (not counting the first three occurrences which are
obviously for other platforms), all three of these include files are
included by os_unix.h at lines 28, 29 and 56.

Best regards,
Tony.
--
Ingrate, n.:
A man who bites the hand that feeds him, and then complains of
indigestion.

[Tony Mechelynck]

P.S. I have the same /usr/include/stdint.h as you do (at least, at lines
51-54).

Now let's try to find out all the places where that uint32_t symbol is
defined or used:

used 44 times in /usr/include/netinet/in.h
defined once in /usr/include/stdint.h
used once in /usr/include/bits/netdb.h
used 3 times in vim.h as follows:
vim.h|54| <<UINT32_TYPEDEF>> #define UINT32_TYPEDEF uint32_t
vim.h|58| <<defined>> #if defined(uint32_t)
vim.h|59| <<UINT32_TYPEDEF>> #define UINT32_TYPEDEF uint32_t
used twice in /usr/include/netdb.h

I think the relevant one is the one at vim.h:54

Best regards,
Tony.
--
May a Misguided Platypus lay its Eggs in your Jockey Shorts

[James Vega]

On Tue, Jun 22, 2010 at 3:03 PM, Charles Campbell
<Charles.E...@nasa.gov> wrote:

> Hello,
>
> I just attempted to update my copy of vim 7.2 with:
>
>      (date && hg pull -u) 2>&1 |tee -a ../hg-vim.log
>
> I followed that up with a   gmake distclean
> and                                     ./configure --with-features=huge
> --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp
> --enable-gnome-check --enable-cscope
>
> Configure failed with the following message:
>
> checking size of off_t... configure: error: in
> `/home/cec/.SW/VIM/Merc/vim/src':
> configure: error: cannot compute sizeof (off_t)
>
> Here's some excerpts from config.log:  (a centos 5.2 system)

Since CentOS 5.2 uses libraries a bit older than the systems I normally
test on, I setup a VM to see if it was something specific to the
library/toolchain versions in 5.2. I installed CentOS, made a fresh
clone of the Vim repository, updated to the vim73 branch, and ran the
configure line you gave above. Everything ran fine for me and I was
able to build Vim.

Given that, I'm not sure why you're seeing different results, unless the
different architecture is affecting things somehow (your 64-bit x86_64
vs. my 32-bit x86).

[Charles Campbell]

James Vega wrote:
> On Tue, Jun 22, 2010 at 3:03 PM, Charles Campbell
> <Charles.E...@nasa.gov> wrote:
>
>> Hello,
>>
>> I just attempted to update my copy of vim 7.2 with:
>>

>> (date&& hg pull -u) 2>&1 |tee -a ../hg-vim.log

>>
>> I followed that up with a gmake distclean
>> and ./configure --with-features=huge
>> --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp
>> --enable-gnome-check --enable-cscope
>>
>> Configure failed with the following message:
>>
>> checking size of off_t... configure: error: in
>> `/home/cec/.SW/VIM/Merc/vim/src':
>> configure: error: cannot compute sizeof (off_t)
>>
>> Here's some excerpts from config.log: (a centos 5.2 system)
>>
> Since CentOS 5.2 uses libraries a bit older than the systems I normally
> test on, I setup a VM to see if it was something specific to the
> library/toolchain versions in 5.2. I installed CentOS, made a fresh
> clone of the Vim repository, updated to the vim73 branch, and ran the
> configure line you gave above. Everything ran fine for me and I was
> able to build Vim.
>
> Given that, I'm not sure why you're seeing different results, unless the
> different architecture is affecting things somehow (your 64-bit x86_64
> vs. my 32-bit x86).
>

Thank you for going to all that trouble! I started getting additional
messages (like "configure: error: `CC' was not set in the previous run")
and make distclean wouldn't complete. So, I applied "/bin/rm -rf" to
the vim directory, and pulled a new copy. This time it configured and
compiled without problems. I suppose I should've tried that earlier.

Regards,
Chip Campbell

[Shubham Purwar]

Hi,

I haved faced same issue in centos 6.6 while upgrading vim to latest vim version(vim 8).

In my machine it is gcc compiler version problem. My previous gcc version in centos 6.6 is 4.8

I have resolved it by upgrading my gcc to gcc 5.5. After that it has installed.

[Tony Mechelynck]

FWIW, my present gcc version is 4.8.5 (from my openSUSE distro,
release Leap 42.3) and I have no problems compiling Vim. The way I do
it is described at:

http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
(getting the source)
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm (once the
source is downloaded)

Sometimes I've seen Vim stop functioning after an OS release upgrade;
running "make reconfig" (which reconfigures and recompiles everything
from the ground up) cured the problem it every time.

Note that my configure settings are set by means of environment
variables, so that I never run configure other than through make, and
that whenever make decides to reconfigure it does so according to my
own configure settings.

Best regards,
Tony.

[tooth pik]

you don't use git?

--
--
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

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tony Mechelynck]

On Thu, Oct 26, 2017 at 7:19 PM, tooth pik <toot...@gmail.com> wrote:
> you don't use git?
>

No I don't, not for Vim anyway. Somehow I understand Mercurial but not
git, so given a choice between them I always choose Mercurial. (For
instance, does git have a specific function to list incoming
changesets, other than "git pull --dry-run"? I like the "log-style"
format of "hg incoming".) This said, whichever way you use to download
the sources, the compunix.htm (or, for Windows, compile.htm) on my
skynet.be user site will still help you compile it.

Best regards,
Tony.

[Marius Gedminas]

On Sat, Oct 28, 2017 at 02:50:48AM +0200, Tony Mechelynck wrote:
> On Thu, Oct 26, 2017 at 7:19 PM, tooth pik <toot...@gmail.com> wrote:
> > you don't use git?
> >
> No I don't, not for Vim anyway. Somehow I understand Mercurial but not
> git, so given a choice between them I always choose Mercurial. (For
> instance, does git have a specific function to list incoming
> changesets, other than "git pull --dry-run"? I like the "log-style"
> format of "hg incoming".)

I've a git alias `incoming` for this:

# ~/.gitconfig
[alias]
incoming = !git fetch && git log --oneline ..@{u}

(I do not remember what the format of `hg incoming` is.)

I also have another git alias, `new`, that shows me the contents of the
last pull after I've done it:

new = !sh -c 'git log $1@{1}..$1@{0} "$@"'

Regards,
Marius Gedminas
--
/*
* This function is about (re)setting the class of a held lock,
* yet we're not actually holding any locks. Naughty user!
*/

[Christian Brabandt]

On Mo, 30 Okt 2017, Marius Gedminas wrote:

> On Sat, Oct 28, 2017 at 02:50:48AM +0200, Tony Mechelynck wrote:
> > On Thu, Oct 26, 2017 at 7:19 PM, tooth pik <toot...@gmail.com> wrote:
> > > you don't use git?
> > >
> > No I don't, not for Vim anyway. Somehow I understand Mercurial but not
> > git, so given a choice between them I always choose Mercurial. (For
> > instance, does git have a specific function to list incoming
> > changesets, other than "git pull --dry-run"? I like the "log-style"
> > format of "hg incoming".)
>
> I've a git alias `incoming` for this:
>
> # ~/.gitconfig
> [alias]
> incoming = !git fetch && git log --oneline ..@{u}
>
> (I do not remember what the format of `hg incoming` is.)

So do it :)

However, one might also want to check git shortlog

Christian
--
Das Leben besteht in dem, was ein Mensch den ganzen Tag über denkt.
-- Ralph Waldo Emerson

[Nikolay Aleksandrovich Pavlov]

2017-10-30 16:51 GMT+03:00 Marius Gedminas <mar...@gedmin.as>:
> On Sat, Oct 28, 2017 at 02:50:48AM +0200, Tony Mechelynck wrote:
>> On Thu, Oct 26, 2017 at 7:19 PM, tooth pik <toot...@gmail.com> wrote:
>> > you don't use git?
>> >
>> No I don't, not for Vim anyway. Somehow I understand Mercurial but not
>> git, so given a choice between them I always choose Mercurial. (For
>> instance, does git have a specific function to list incoming
>> changesets, other than "git pull --dry-run"? I like the "log-style"
>> format of "hg incoming".)
>
> I've a git alias `incoming` for this:
>
> # ~/.gitconfig
> [alias]
> incoming = !git fetch && git log --oneline ..@{u}
>
> (I do not remember what the format of `hg incoming` is.)

`hg incoming` has exactly the same format as `hg log`, including
ability to use `--template`. But it does not save anything and it
works with whatever branch(es) you need. I would say that it would be
hard to have yours `incoming` or `new` if you want to get more then
one branch with one command, and configuring git to pull in all
branches from remote at once is normally the first thing I do.

>
> I also have another git alias, `new`, that shows me the contents of the
> last pull after I've done it:
>
> new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
>
> Regards,
> Marius Gedminas
> --
> /*
> * This function is about (re)setting the class of a held lock,
> * yet we're not actually holding any locks. Naughty user!
> */
>

> --
> --
> 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
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.

[Tony Mechelynck]

Another thing I don't like (or maybe don't understand) in git is the
existence of "garbage collection". On the contrary, a basic tenet of
Mercurial philosophy is that history is frozen in stone, so if I let a
clone stand without updating it for, let's say, a year, and then run
"hg pull -u" or "hg fetch", Mercurial will be able to continue from
where I left off and (barring timeouts and brownouts) get the clone
back up to date. Once I did that with git, and when I came back after
a year my clone was so hopelessly out of date that git didn't know how
to update it: the only way I found to make it up to date again was to
delete the clone and make a new one.

Best regards,
Tony.
P.S. Happily for me, Christian understands both of them (or ;-) seems
to) so I enjoy the luxury of a Mercurial mirror to Bram's git
repository.

[Christian Brabandt]

On Mi, 01 Nov 2017, Tony Mechelynck wrote:

> Another thing I don't like (or maybe don't understand) in git is the
> existence of "garbage collection". On the contrary, a basic tenet of
> Mercurial philosophy is that history is frozen in stone, so if I let a
> clone stand without updating it for, let's say, a year, and then run
> "hg pull -u" or "hg fetch", Mercurial will be able to continue from
> where I left off and (barring timeouts and brownouts) get the clone
> back up to date. Once I did that with git, and when I came back after
> a year my clone was so hopelessly out of date that git didn't know how
> to update it: the only way I found to make it up to date again was to
> delete the clone and make a new one.

If I understood correctly garbage collection in git, this only affects
any object, that is not reachable, so it should in practice not matter
for the usual case.

> P.S. Happily for me, Christian understands both of them (or ;-) seems
> to)

More or less :)

Christian
--
Der Begriff "Fortschritt" allein setzt bereits die Horizontale voraus.
Er bedeutet ein Weiterkommen und keine Höherkommen.
-- Joseph Roth