Is it possible to compile in Windows?

[ferfebles]

Hi,

It is almost impossible to use a terminal inside Emacs with Windows.

Is there any way of use emacs-libvterm in Windows?

[akermu]

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

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

[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

[mikereape]

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

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

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

[vleonbonnet]

It is pretty straight forward to compile, was able to do it on a fresh MSYS2 install. Open MSYS2 terminal with no environment:

• Press 'Win' key to open the Windows menu.
• Type "msys2" to select MSYS2 environment.

pacman -S --noconfirm libtool cmake
/usr/bin/emacs

Then just press 'y' when prompted to compile the module.

My .emacs:

(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el"
                         user-emacs-directory))
      (bootstrap-version 6))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/radian-software/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

(straight-use-package 'use-package)
(setq straight-use-package-by-default t)
(use-package vterm)

[sprig]

@vleonbonnet I was able to build in msys2 and it runs fine in emacs in the msys2 terminal but native emacs fails to load the dll. Were you able to make it run outside of msys2?

On a fresh msys2:

$ pacman install -Sy cmake make gcc libtool git
$ cd .emacs.d/elpa/vterm-xxx
$ cmake .
$ make

At this point one can install emacs and test:

$ pacman install -Sy emacs
$ make run

and a vterm inside emacs pops up.
However, in native emacs I get Module could not be opened: .../vterm-module.dll, The specified module could not be found.

[vleonbonnet]

@sprig I had the same issue with native emacs, and ended making a patch to make it work.

See https://github.com/vleonbonnet/emacs-libvterm
This works for me albeit a little slow. It might actually be better to use cygwin.

Still need to be cleaned-up to do a pull request in this repo, but I am unable to find the time right now.

I should add that this patch requires fakecygpty, which I ended up doing a fork as well. My config:

(use-package fakecygpty
  ;; Not available on elpa. Use my fork which adds MSYS2 support.
  :straight (fakecygpty :host github :repo "d5884/fakecygpty" :fork t)
  ;; Only required on Windows
  :if (eq system-type 'windows-nt)
  :config
  ;; Enable
  (fakecygpty-activate))

https://github.com/vleonbonnet/fakecygpty

[sprig]

Very interesting, thanks!

[Vidianos-Giannitsis]

What's the status of this ? Trying to get vterm to work on my work laptop so I can get Julia-snail up and running.

I have the same issue as @sprig . Should I build from @vleonbonnet 's fork ? Is the speed slow enough to justify me dropping to terminal emacs in msys when I want to use this? I'm curious, because this feels like it's so close to working, and it's a shame if I can't get it going.

[vleonbonnet]

I haven't had the chance to look more into this, as I rarely use Windows these days. I think this is pending a proper pull request to be submitted so that it can be fixed for everyone. I don't remember how slow it was, but it was still usable. Besides, slow is still better than broken.

To answer your question, the issue is actually closed, best next steps would be to convince someone with the permissions to re-open it and submit a pull request.