Is it possible to compile in Windows? about emacs-libvterm

[mikereape]

Hi

I'd like to reopen this if possible because I've been trying very hard the last couple days or so to build emacs-libvterm on Windows and have been struggling a bit with getting neovim/libvterm compiled. This will be a long comment but I believe I'm nearly there. I should point out that I'm using GNU Emacs 27.2 (build 1, x86_64-w64-mingw32) on Windows 11 preview (until very recently Win 10 Pro) that I installed from chocolatey. In general the Emacs really is quite stable despite how I abuse it by pushing it to its limits.

In a nutshell when I followed your default recommended instructions for installing emacs-libvterm the install did in fact download and try to build libvterm but there were so many problems it wasn't worth pursuing. So instead, I decided to download the tar file off neovim/libvterm at github and try to compile it directly. That is the subject of this comment.

The first thing I had to do was get the libtool library installed because something was missing. I was able to get that from the GnuWin32 site. I used the mingw64 part of the msys64 distribution more or less out of the box to try to do the compile. It complained abut termios.h being missing so I found that at https://kernel.googlesource.com/pub/scm/linux/kernel/git/nico/archive/+/v0.01/include and just copied termios.h into the include directory in libvterm. That resolved that issue. Then I started again. That's all detailed in [libvterm compile.log](https://github.com/akermu/emacs-libvterm/files/6833997/libvterm.compile.log) attached which is quite long. The gist of it is that it does a static build rather than a dll build because "visibility attribute not supported in this configuration; ignored [-Wattributes]". I was fine with that for very many reasons. However, at the end it complained that "undefined symbols not allowed in x86_64-w64-mingw32 shared libraries; building static only". That's at the end of the log. Note also immediately after that that it says:

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\miker\AppData\Local\Temp\cc4NBM0H.o:vterm-ctrl.c:(.text+0x27b): undefined reference to `tcgetattr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\miker\AppData\Local\Temp\cc4NBM0H.o:vterm-ctrl.c:(.text+0x2d3): undefined reference to `tcsetattr'

I expected that to be a problem. The "visibility attribute" stuff was introduced long after I stopped being a Unix/Linux hacker. I could use some advice on what to do here.

Thinking that the problem might have to do with the msys2 installation I reinstalled my MinGW installation from scratch (that is, separate from the msys2 install) from the http://mingw-w64.org/doku.php site via the mingw-w64-install.exe installer and the mingw-get-setup.exe tool ("MinGW Installation Manager").

Then I tried again with a fresh copy of neovin/libvterm. That'ss all detailed in libvterm compile.2.log libvterm compile.2.log
and indeed things went better. However, I was left with this (at the end of the log):

bin/vterm-ctrl.c: In function 'read_csi':
bin/vterm-ctrl.c:117:10: warning: implicit declaration of function 'strdup' [-Wimplicit-function-declaration]
   return strdup(csi);
          ^~~~~~
bin/vterm-ctrl.c:117:10: warning: return makes pointer from integer without a cast [-Wint-conversion]
   return strdup(csi);
          ^~~~~~~~~~~
bin/vterm-ctrl.c: In function 'read_dcs':
bin/vterm-ctrl.c:142:10: warning: return makes pointer from integer without a cast [-Wint-conversion]
   return strdup(dcs);
          ^~~~~~~~~~~
C:\Users\miker\AppData\Local\Temp\ccs4Y5is.o:vterm-ctrl.c:(.text+0x1a9): undefined reference to `tcgetattr'
C:\Users\miker\AppData\Local\Temp\ccs4Y5is.o:vterm-ctrl.c:(.text+0x206): undefined reference to `tcsetattr'
collect2.exe: error: ld returned 1 exit status
Makefile:72: recipe for target 'bin/vterm-ctrl' failed
mingw32-make: *** [bin/vterm-ctrl] Error 1

I can only think/guess strdup is a/the C string duplication function. I could carry on my merry way this way but at this point I'd really just be fumbling round in the dark.

Everything seems to hinge on getting vterm-ctrl.c to compile. That has consistently been the probleem.

I would be very grateful for any comments/recommendations/suggestions. You would be doing a tremendous number of people a whole lot of good if this could be resolved successfully.

BTW, FWIW, I'm opening to open a new issue about how emacs-libvterm works, in particular, the part that integrates the terminal window into an Emacs window/buffer/frame/whatever the Emacs terminology is.

Thanks very much in advance

Mike

[akermu]

It's possible to compile it, but it doesn't work as windows lacks an PTY interface. But that changed recently: https://blogs.msdn.microsoft.com/commandline/tag/pty/. We should get emacs to use it, so this can become useful under windows.

[Sbozzolo]

Thanks for your efforts. This question should be asked to the developers of libvterm, but from your log I guess the main problem is with the function tcgetattrt. This is defined in the termios.h header file, which is not available on Windows. However, I don't think that vterm-ctrl is needed at all (I am guessing), so you can try ignored it.

[akermu]

Never tried it, but you could try to compile this module with mingw32.

[mikereape]

Hi sorry I seemed to have not got the first log attached. I try again
libvterm compile.log

[xuehy]

Is it possible to use termiWin to include termios.h on windows?

[takase1121]

Just remove everything from the bin directory and you're golden. The lib itself doesn't require termios.h, only vterm-ctrl.c does.

[derinsh0]

I thought this was an interesting problem. I don’t know if I have a use-case for vterm, but I was curious and went ahead to try and compile. As @mikereape stated, libvterm won’t compile due to termios.h, I used termiWin as @xuehy referred to and I successfully built libvterm. When installing vterm from emacs and building the module, you have to first make changes to CMakeLists.exe in elpa vterm dir (it also requires termios.h), making it include termiWin source file and the gcc D-flag stated in termiWin repo. After that vterm for emacs is compiled successfully.

Vterm is very close to functional, there is one problem though, that’s Emacs’s term mode doesn’t work on Windows, since it is hard-wired to look for /bin/sh. I.e. starting vterm will yield “Spawning child process error” which is pretty infamous for emacs-w32. So I found this https://github.com/d5884/fakecygpty but I don’t think it worked.

What I tried was create C:\bin\sh.bat with the contents pwsh and I successfully made vterm open a powershell prompt and run commands. But it was very buggy; I couldn’t delete characters and movement commands weren’t accurate.

[Sbozzolo]

I don't know if it helps, but you can change the process being run by customizing the `vterm-shell` variable.

…

On Wed, Aug 10, 2022 at 1:54 PM psisis ***@***.***> wrote: I thought this was an interesting problem. I don’t know if I have a use-case for vterm, but I was curious and went ahead to try and compile. As @mikereape <https://github.com/mikereape> stated, libvterm won’t compile due to termios.h, I used termiWin as @xuehy <https://github.com/xuehy> referred to and I successfully built libvterm. When installing vterm from emacs and building the module, you have to first make changes to CMakeLists.exe in elpa vterm dir (it also requires termios.h), making it include termiWin source file and the gcc D-flag stated in termiWin repo. After that vterm for emacs is compiled successfully. Vterm is very close to functional, there is one problem though, that’s Emacs’s term mode doesn’t work on Windows, since it is hard-wired to look for /bin/sh. I.e. starting vterm will yield “Spawning child process error” which is pretty infamous for emacs-w32. So I found this https://github.com/d5884/fakecygpty but I don’t think it worked. What I tried was create C:\bin\sh.bat with the contents pwsh and I successfully made vterm open a powershell prompt and run commands. But it was very buggy; I couldn’t delete characters and movement commands weren’t accurate. — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACF6E7MV2LKWSS2P6QN4TUTVYQJIXANCNFSM4FBT6XXA> . You are receiving this because you commented.Message ID: ***@***.***>

[derinsh0]

That didn't give any effect. It was set correctly to cmdproxy.exe. I think the problem is in vterm.el line 711:

...
(setq vterm--process
      (make-process
       :name "vterm"
       :buffer (current-buffer)
       :command
       `("/bin/sh" "-c"
         ,(format
...

It looks to be hardcoded to launch /bin/sh

[mateialexandru]

Any luck with this?

[hkjels]

Why was this closed? Is it somehow fixed?