Hi again On Wednesday, 18 March 2020 11:39:03 UTC, Mike Williams wrote: > > Hi > > On Wednesday, 18 March 2020 11:01:22 UTC, Dominique Pelle wrote: >> >> Mike Williams wrote: >> >> > Hi, >> > >> > I am trying to build a terminal version of VIM that includes terminal >> > support. My build line run in the src directory are: >> > >> > nmake -nologo -f make_mvc.mak TERMINAL=yes FEATURES=BIG >> > >> > The final link fails with: >> > >> > vterm_unicode.obj : error LNK2001: unresolved external symbol >> utf_uint2cells >> > vterm_unicode.obj : error LNK2001: unresolved external symbol >> > utf_iscomposing_uint >> > vim.exe : fatal error LNK1120: 2 unresolved externals >> > >> > The invoked compilation command is: >> > >> > cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE >> > -DFEAT_TERMINAL -DFEAT_SOUND -DWINVER=0x0501 >> > -D_WIN32_WINNT=0x0501 /source-charset:utf-8 /MP -DHAVE_STDINT_H /Ox >> > /GL -DNDEBUG /Zl /MT /D_CRT_SECURE_NO_DEPRECATE >> > /D_CRT_NONSTDC_NO_DEPRECATE -DFEAT_MBYTE_IME -DDYNAMIC_IME >> > -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON >> > -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_BIG /Fd.\ObjCYAMD64/ /Zi >> > /Fo.\ObjCYAMD64/ ... >> > >> > The missing symbols are from mbyte.c and checking there I can see they >> > are compiled in if FEAT_TERMINAL is defined, which it appears to be. >> > And yes mbyte.c appears in the list of files to compile and compiled. >> >> Strange, it can't see why it happens. >> Maybe make_mvc.mak is missing a dependency and it's >> linking with an old object file as a result? >> Can you do do a clean build to make sure that this is not the issue? >> >> Regards >> Dominique >> > > Yeah, I should have said I thought of that and made sure there were no > unexpected .obj files lying around. I have done a clean debug build so I > can dumpbin the symbols in mbyte.obj, and sure enough the symbols do not > appear in it. > > Ah, full disclosure. I normall build gui followed by terminal versions. > Using #error to check the functions were being built did fail with the gui > build, indicating that FEAT_TERMINAL was defined - I just assumed the same > with the terminal version. I then simplified the build script to just > build the terminal version which continued to fail. Retrying the #error > trick now shows the functions are not being compiled in even though > FEAT_TERMINAL is in the cl command. > > So, the issue is that FEAT_TERMINAL is being undefined for windows > terminal builds by features.h because FEAT_JOB_CHANNEL is not being > defined. I guess the vterm code is not picking up feature.h and missing > the redefinition of flags from the compile command. > > I don't define this for gui builds so dont do it for terminal builds - > should I? Or is this an issue in the MSVC makefile being inconsistent? > > TIA - TTFN > > Mike >
Ok, I have sorted out how to get it to build, I need to include CHANNEL=yes otherwise terminal support is cleared in feature.h. CHANNEL is set for FEATURES=BIG or inherits the GUI setting which is why the GUI build was succeeding. At it's simplest the MVC make file (and others?) needs to note that channel is needed for terminal support in the same way netbeans support notes this. After that it is a judgement call if selecting terminal should enable channel support or not. Handling this in the actual C source doesn't seem feasible if the vterm code is separate to the core VIM source. My 2ps worth. TTFN Mike -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/3323fcae-0830-49a0-96e7-545d1466b4d0%40googlegroups.com.
