Loading ...
Sorry, an error occurred while loading the content.

Trying to compile: What Did I Do Wrong?

Expand Messages
  • Antoine J. Mechelynck
    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
    Message 1 of 38 , May 22, 2004
    • 0 Attachment
      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:

      HOME=D:\HOME
      VIM=C:\PROGRA~1\VIM
      BOR=D:\PROGRA~1\BORLAND\BCC55
      USERNAME=antoine.mechelynck
      USERDOMAIN=belgacom.net

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

      vim63bsrc.zip
      vim63brt.zip
      vim63blang.zip

      Unzip them there using WinZip. The files they contain are written in or
      under .\vim\vim63b

      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
      patches).

      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:

      gvim.exe
      vimrun.exe
      install.exe
      uninstal.exe
      gvimext\gvimext.dll
      xxd\xxd.exe

      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
      displays OK.

      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.*":

      gvim.exe.mnf
      gvim.ils
      gvim.ilf
      gvim.ilc
      gvim.ild
      gvim.tds
      gvim.exe
      gvim.map

      The first of them is dated 16-May-2004 16:59, all others 23-May-2004 03:29.

      Regards,
      Tony

      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
      +clientserver
      +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
      +cryptv -cscope +dialog_con_gui
      +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search
      +farsi +file_in_path
      +find_in_path +folding -footer +gettext/dyn -hangul_input +iconv/dyn
      +insert_expand +jumplist
      +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
      +mksession +modify_fname
      +mouse +mouseshape +multi_byte_ime/dyn +multi_lang
      +netbeans_intg -ole -osfiletype +path_extra
      -perl -postscript +printer -python +quickfix +rightleft -ruby +scrollbind
      +signs +smartindent
      -sniff +statusline -sun_workshop +syntax +tag_binary
      +tag_old_static -tag_any_white -tcl -tgetent
      -termresponse +textobjects +title +toolbar +user_commands +vertsplit
      +virtualedit +visual
      +visualextra +viminfo +vreplace +wildignore +wildmenu +windows
      +writebackup -xfontset -xim
      -xterm_save -xpm_w32
      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"
      Compilation:
      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
      Linking:
      D:\PROGRA~1\BORLAND\BCC55\BIN\ILink32 -OS -Tpe -c -m -LD:\PROGRA~1\BORLAND\B
      CC55\lib -aa
    • Bruce Mellows
      ... What I have done is to provide the API functions myself, which then switch explicitly to the dll s - it works, but I am not sure why, I could trace into
      Message 38 of 38 , Jun 8 5:42 PM
      • 0 Attachment
        Bram Moolenaar wrote:

        >Bruce Mellows wrote:
        >
        >
        >
        >>>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.
        >
        >
        >
        What I have done is to provide the API functions myself, which then
        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 present
        >>>>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?
        >
        >
        >
        I don't have the source for the BC5.5 libraries and the BC4.5 source
        does not have wstat - so we are just guessing

        >>>I think that for us to be sure it really works we need to know the
        >>>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
        >problems.
        >
        >
        >
        If you don't want to pursue this, then that's your call of course.
      Your message has been successfully submitted and would be delivered to recipients shortly.