Bear not building on MinGW64 #431
Comments
|
Hey @FrostKiwi , I've made a fix for this. It's on the |
Looks like progress :] It's not complaing about missing syscalls anymore. |
|
I'm sorry @FrostKiwi , it was a typo. (I wrote |
|
Hahaha, that's a fail for me as well. I thought "missing binary operator" is something easy, so I stared at it for a good minute and gave up. One thing down, one more to go, at least as per my log: Thx for supporting esoteric programming setups with so much passion and love <3 |
|
I'm guessing here: I think the name |
|
Guard.cc, Os.cc and Flags.cc don't complain anymore. 🎉 |
|
Looks like your compiler is more pedantic and was not called the implicit conversion from |
|
Path.cc succesfully cleared 🎉 Right the next source file complains ;____; make log with error from Process.cc |
|
This I don't know how to fix. Yet. Can you pass the I'll also need to see what are the content of the MinGW header files. Is that available somewhere on GitHub or some public repository? |
|
Uploading text files is forbidden ( I mean it's GitHub, what's the logic O.o ) config.h from Bear\build\subprojects\Build\BearSource after cmake ran as part of the make build commandWhether there is a public place to look at how the includes look, I think no. There is a public package listing for all of MSYS2: https://packages.msys2.org , but the filesystem is built via the package manager and each package contributing it's contents. So virtual machine + installing MSYS or a straight up Windows machine is propably the way to go? I know you can cross-compile with MinGW64 packages to Windows from Linux, but that possibly(?) changes what layout we are working with.
So here is what I did for the sake of providing something useful - I archived the MSYS include directory from /usr/include here: Output of Tree from msys64\usr\include (Includes what the base MSYS environment provides)And here the same for the MinGW64 include directory, which is a real chonker: Output of Tree from msys64\mingw64\include (Includes what the MinGW64 environment provides)edit: Actually I'm not sure about that last statement. Since MinGW64 is another environment, maybe MSYS includes dont matter. Those provide different C libraries after all. After a bit of thinking, maybe only the mingw64 includes play a role, I'll ask for context, out of my own curiosity aswell. |
|
Thanks so much @FrostKiwi this is very good... After a quick look, I see that there is no |
|
In the MinGW64-packages repo issue it was mentioned... msys2/MINGW-packages#7411 (comment)
...Maybe I'm creating the wrong approach here. Bear might be more of a basic sysutil and may not need to be compiled with the Windows-Native MinGW64 toolchain. Only thing regarding fork I find is this comment: https://news.ycombinator.com/item?id=11391797 There does not seem to be a spawn.h and there man fork returns just GNU awk's fork man page. Though I have zero idea how any of this works or how to compile for MSYS, instead of the Windows native MinGW64... |
|
Oh, so there is no POSIX layer in MinGW. And Bear should call Windows native... That will be challenging. |
|
I asked around and maybe my it really is the best to not build Bear Windows native and not try to square the circle.
And again when I asked yesturday: msys2/MINGW-packages#7411 (comment)
So since Bear is more of a tool close to the system, maybe it should remain within the MSYS environment and get access to all that emulated POSIX goodness. Unfortunately I have zero idea how to build in that environment or how to get those emulated Posix features. |
|
Hi all, I kind of stuck in windows. So, are there any progress here? I am using mingw-w64 as well. Bear cannot be built on msys2 environment alone because Bear's dependencies doesn't exist as msys2 package. I tried building Bear on mingw-w64 after installing dependencies. I am a bit confused here. Bear doesn't seem to have the macro definitions to see these system headers as posix headers: configure output:
$ cmake -DENABLE_UNIT_TESTS=OFF -DENABLE_FUNC_TESTS=OFF .. Build output
$ ninja Environment variables
$ env Bear version: c5fb0ea I'll be happy to help & provide more details. |
|
Hey @memoks , thanks for the follow up... There are no progress on this unfortunately. The code is written mostly by me, who has experience and access for POSIX based OSes. Happy to have contributions to port some of the OS specific parts (process creation) to Windows. |
|
If you intend to use Bear to make LSP to work properly from within MSYS2, here are some alternatives that all worked for me. Works flawlessly. Clangd has the same thing ( https://clang.llvm.org/docs/JSONCompilationDatabase.html#alternatives ) , called compile_flags.txt. I wrote them manually, but now just autogenerate the .ccls file with my Makefile. Alternatively, if you compile with clang, you have the ability to output the json formatted compilation database information ( https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mj-arg ), if your project is more complex than what a single compile flags collection can express. All these worked for me, but I ended up using ccls and simply outputting the .ccls file. |
|
Hi all, @FrostKiwi Huge thanks for the suggestions. I am, in fact, trying to get LSP+emacs to work :). Unfortunately, my project is a a bit complex where compilation commands can change on per file basis. And I am using GNU compiler toolchain. One approach, as you have pointed out, would be to have the makefiles output compilation commands. This should be very easy through changing makefiles (if they are well organized). But this is not the case and I don't have the permission to change all the makefiles. So, I am trying to work around this for now. @rizsotto After evaluating the situation further, maybe using mingw was a mistake. Out of curiosity, I am trying to compile Bear using cygwin this time. Because cygwin is basically POSIX this should work if I can manage the dependencies. I will write the steps if it succeeds. And there is also WSL (Windows subsystem for Linux) which I don't have atm and probably is the better way to do this. |
|
@memoks also Emacs + LSP here :] Both cygwin and WSL2 would indeed sidestep the problem, but it depends on your use-case. AFAIK, Cygwin means shipping a bunch (maybe just 1?) of .dll files with your program, creating an extra dependency and WSL2 requires the whole WSL2 subsystem to be installed for the program to run. That's the reason I stuck with MinGW64, as you can produce dependent free binaries, for the installer-free user experience. |
|
@FrostKiwi You are right about .dll files and dependencies. Mingw is the most dependency free compared to other alternatives. Unfortunately, cygwin could not sidestep the problem here. One of the dependencies of grpc, doesn't support cygwin.
In file included from /cygdrive/c/Users/mehmet.basaran/Desktop/cyg32/Bear-master/build/subprojects/Source/grpc_dependency/third_party/abseil-cpp/absl/base/config.h:67, |
As reported in the MinGW64-packages repo: msys2/MINGW-packages#7411 and in this issue: #427 , Bear does currently not build on MSYS2 + MinGW64. Since that Bear repo issue is closed, I thought I open up this one to properly present info regarding this issue.
Describe the bug
Building Bear in with MSYS2 and it's MinGW64 environment fails.
The main culprit is the missing 'confstr'
Os.cc:49:2: error: #error "System call "confstr" not exists.", which is apparently not present with this Unix environment.Configure log from 'cmake -G "Unix Makefiles" -DENABLE_UNIT_TESTS=OFF -DENABLE_FUNC_TESTS=OFF ..'
Compile log end error from 'make'
For completion sake here is the output of
env, which shows how the MinGW64 environment is setup and the corresponding PATH variable.Full output of 'env'
To Reproduce
Install MSYS2 and the GNU Toolchain
mingw-w64-x86_64-toolchainvia pacman.Open up the MinGW64 environment, via the "MSYS2 MinGW 64-bit" shortcut. Try to compile Bear.
Environment:
I'm happy to quickly test any suggested solution.
The text was updated successfully, but these errors were encountered: