Trying to compile: What Did I Do Wrong?
- I'm at wits' end. (When Bram compiles gvim 6.3b.0, it can read my files even
with &enc == "utf8". When I do, it cannot.)
Kernel is W98 SE 4.10.2222 with (AFAIK) all "Windows Updates" so far.
Here's what I did:
C:\AUTOEXEC.BAT now defines (among others) the following environment
variables, which are expected to stay constant:
%BOR%\BIN is first in the PATH. %VIM%\vim63b comes somewhat later (both of
them in expanded form).
In directory %BOR%\BIN, renamed (to keep them from interfering)
bcc55.cfg to bcc55.xfg
ilink32.cfg to ilink32.xfg
builtins.mak to builtins.txt
Several reboots have happened since then.
Installed gvim.exe (6.3b.0, by Bram@KIBAALE) and the corresponding vim.exe,
from the self-installing .exe archive, telling it to uninstall all other
versions of Vim. (Cygwin gvim was removed manually, including its softlinks
in /usr/bin). After I confirmed its suggestion, Vim 6.3b installed itself in
and under %VIM%\vim63b. Launched it. :ver confirms that I got the right one.
Experiment shows than it can read all files, even UTF-8 ones, and even when
'enc' is set to "utf-8".
Created the directory D:\Downloads\vim\src. CD to it. It has no
subdirectories. The following files (dated 18 May 2004) have been downloaded
to it from the ftp.vim.org site:
Unzip them there using WinZip. The files they contain are written in or
CD to .\vim\vim63b\src. There is a .bat file there (bigvim.bat) but I can't
use it (it refers to a different compiler than mine). Create another one
(named buildvim.bat) with the command
make -fMake_bc5.mak -B %1 %2 %3 %4 %5 %6 %7 %8 %9
(the -B parameter to Borland make means "build from scratch, regardless of
timestamps". This is to force rebuild if, for instance, I later try an i686
build.) No changes were made to the makefile (trying to build a vanilla gvim
and expecting that the environment will take care of everything
nonstandard). No patching yet (if this works, I'll eventually apply the 6.3b
Check that the current shell is COMMAND.COM, that %COMSPEC% points to it,
and that %SHELL% is not defined.
Run "Make /?" to check that it is Borland Make, not something else. It is.
BCC32 with no arguments gives a page of "usage help" headed by the line:
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Run the above batch file (buildvim), with no additional command-line
arguments. A lot of information messages (mostly names of source modules,
now and then a long command line, etc), but nothing I can interpret as an
error or even a warning. The following binaries are built:
Launch gvim. It starts up. Save its ":version" listing to the clipboard (see
below). Try ":set enc=utf8" followed by ":h". No go (same symptoms as with
late 6.2 or early 6.3a). Then ":set enc=latin1" followed by ":h". Help
So: How come that, with (apparently) the same sources, the same runtime
files (I checked $VIMRUNTIME and it is set to the same value in both cases),
the same vimrc ($HOME is the same) and with (AFAICT) no relevant differences
in the set of features, Bram's program can read files even when &enc ==
"utf-8" and mine cannot?
NB: ":version" listing follows (OE6 may have "beautified" it with extra
linbreaks but I hope you can understand it anyway). A file named "gvim.map"
was found in the src directory, It is the link map with globals produced by
ilink32. I first thought I would include it as an attachment but it's 239K
long. I have uploaded it to
http://users.skynet.be/antoine.mechelynck/other/gvim.map instead. Here is
the list of the files shown by "dir gvim.*":
The first of them is dated 16-May-2004 16:59, all others 23-May-2004 03:29.
VIM - Vi IMproved 6.3b BETA (2004 May 16, compiled May 23 2004 03:28:04)
MS-Windows 32 bit GUI version
Compiled by antoine.mechelynck@...
Big version with GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv -cscope +dialog_con_gui
+diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search
+find_in_path +folding -footer +gettext/dyn -hangul_input +iconv/dyn
+keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
+mouse +mouseshape +multi_byte_ime/dyn +multi_lang
+netbeans_intg -ole -osfiletype +path_extra
-perl -postscript +printer -python +quickfix +rightleft -ruby +scrollbind
-sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl -tgetent
-termresponse +textobjects +title +toolbar +user_commands +vertsplit
+visualextra +viminfo +vreplace +wildignore +wildmenu +windows
+writebackup -xfontset -xim
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME\_vimrc"
2nd user vimrc file: "$VIM\_vimrc"
user exrc file: "$HOME\_exrc"
2nd user exrc file: "$VIM\_exrc"
system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
system menu file: "$VIMRUNTIME\menu.vim"
D:\PROGRA~1\BORLAND\BCC55\BIN\Bcc32 -w-aus -w-par -w-pch -w-ngu -w-csu -ID:\
PROGRA~1\BORLAND\BCC55\include;.;proto -d -RT- -k- -Oi -H -H=vim.csm -Hc -f-
-DFEAT_BIG -DWIN32 -DHAVE_PATHDEF -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -
DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBY
TE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -O2 -f- -d -Ocavi -O
-vi- -W -3 -a4
D:\PROGRA~1\BORLAND\BCC55\BIN\ILink32 -OS -Tpe -c -m -LD:\PROGRA~1\BORLAND\B
- Bram Moolenaar wrote:
>Bruce Mellows wrote:What I have done is to provide the API functions myself, which then
>>>Unfortunately, our experience is that the failure of the Win32 wide
>>>functions does not result in _wstat(), _wopen() and _wfopen() to fail.
>>>This results in strange Vim errors that it can't read files.
>>The _wstat, _wopen and _wfopen functions fail correctly with the
>>modification that I have put forward (I have tested this)
>>There is left, then, the question of what to do when the c-library
>>functions fail, which I assume that vim handles correctly.
>I don't see how this is possible. When unicows.dll is not present
>everything works as before, right? Are you using a different Borland C
>version perhaps? We know it fails with Borland C 5.5.1.
switch explicitly to the dll's - it works, but I am not sure why, I
could trace into it, but that does not seem too important once the
solution is at hand.
Keep in mind that the library must eventually call the API, and its the
API that we are effectively providing.
>>>>Further, I did run a test of _wstat with and without unicows.dll presentI don't have the source for the BC5.5 libraries and the BC4.5 source
>>>>on win98, and the call returns -1 (hooray) when unicows.dll is not present.
>>>How can you explain that this works now but failed before?
>>These now fail correctly. I can't explain why - it guess that Borland
>>may provide linkage to the wide API that fails less predictably (I don't
>>believe this could be the actual explanation - just a possibility)
>I don't like to accept something that I don't understand. Logically
>nothing changes when unicows.dll is not present, so why would the
>library functions behave differently?
does not have wstat - so we are just guessing
>>>I think that for us to be sure it really works we need to know theIf you don't want to pursue this, then that's your call of course.
>>>Borland implementation of _wstat(), _wopen() and _wfopen(). Only then
>>>can we know how they use the wide Win32 functions and how they fail when
>>>they don't work.
>>I have attached a few logs (including stacktraces) of what happens when
>>_wstat, _wopen and _wfopen are called under win2000 and win98 (with and
>>without unicows.dll present)
>This only shows what happens in one situation. We also need to know
>what might happen in different situations. I think this is only
>possible by looking at the source code. Normally I wouldn't be so
>suspicious, but we have already seen that these library functions fail
>in a specific situation. That is a good indication there might be more