Cannot compile Far with MinGW

[shmuz]

1. Installed MinGW from https://github.com/mstorsjo/llvm-mingw
2. Got 5 warnings on each compiled file and then an error (see the file attached)
3. If this MinGW isn't suitable where can I download the "right" MinGW?

out.txt

[alabuzhev]

I use https://www.msys2.org. Our CI uses msys2 too, so it is more or less guaranteed to work.

I have not tried llvm-mingw (or even heard of it), but looks like it's actually clang, renamed to g++.
If so, try passing CLANG=1 to the makefile.

[shmuz]

@alabuzhev
Yes it's clang. Passing CLANG=1 to the makefile produced different warnings but in the end I've got an error again.
So I removed this MinGW from my system.
msys2 must be fine but I'm afraid I'll not be able to compile files from my favorite SciTE editor with msys2.
Will try other options.

[alabuzhev]

@shmuz I tried it and successfully compiled both 32 and 64 error- and warning-free after 960cc4c.

[shmuz]

As for now I've installed from https://github.com/niXman/mingw-builds-binaries
Far compiles with just one warning:

{standard input}: Assembler messages:
{standard input}:4013: Warning: redundant segment overrides

What's weird is that the produced Far.exe is 10 MB while in GitHub releases it's 5 MB.

[zg0]

You can replace -O3 to -Os in makefile_gcc_common and get the same size as vc build, but why?

[shmuz]

@zg0
I thought GitHub builds use gcc and you say vc ?
I just tried to understand what is the reason for the difference in Far.exe sizes.

[zg0]

far.map from github builds looks like from vc, not from gcc.

[shmuz]

OK then this explains why it is small. No 10 MB is not a problem nowadays.

[alabuzhev]

far.map from github builds looks like from vc, not from gcc

which one?

[zg0]

Far.x64.3.0.6210.3537.87154c58588b1cdc6e010c290fa4ebfa717af4c8.7z\Far.map

[alabuzhev]

yes, that one is vc.
gcc artefacts are here.

[alabuzhev]

MinGW from https://github.com/mstorsjo/llvm-mingw

Since this toolchain comes with a completely different standard library, it would be useful to support it.

And now we do.

Overall:

Compiler\Library	Microsoft STL	libstdc++	libc++
Visual C++	✔️
GCC		✔️
Clang	✔️	✔️	✔️

[alabuzhev]

Does the source code of .LNG generator exists somewhere

https://github.com/FarGroup/FarManager/tree/master/misc/lng

could it be compiled for Linux

No idea.
I have a Python version somewhere, I can commit it if anyone finds it useful.

[bitraid]

Does the source code of .LNG generator exists somewhere

https://github.com/FarGroup/FarManager/tree/master/misc/lng

I can't believe I missed it. Unfortunately, the code is not portable.

I have a Python version somewhere, I can commit it if anyone finds it useful.

That would be so much better than running the Windows binary with WINE.

[alabuzhev]

ok

[MKadaner]

I prototyped .LNG file checker which can be used with the proposed split-LNG files. It should not be difficult to add generate .LNG mode. The checker is targeted for .NET Core, so it should natively run on Linux.

@bitraid, if you are interested, let's push split-LNG files feature and I'll turn checker into generator.

[bitraid]

@MKadaner, That sounds great.
Meanwhile, I tested @alabuzhev's script by making a small change to the makefile, and it works fine.

[bitraid]

@alabuzhev, I'm sorry to bother you again on this closed discussion, but would it be possible to make a few of changes to the makefile, for supporting cross-compilation with llvm/clang (basically, be explicit about the tools/libraries, so it won't use the system defaults), and also have the option to use python instead of wine?

Currently, I apply the following patch to make things work:

diff --git a/far/makefile_gcc_common b/far/makefile_gcc_common
index c8672169b..4b492308c 100644
--- a/far/makefile_gcc_common
+++ b/far/makefile_gcc_common
@@ -44,21 +44,29 @@ CP = $(UTILS_PREFIX)cp -f
 MV = $(UTILS_PREFIX)mv -f
 
 ifdef CLANG
-CXX = clang++
+CXX = clang --driver-mode=g++ -stdlib=libc++
 CC = clang
+WINDRES = llvm-windres
+DLLTOOL = llvm-dlltool
+RANLIB = llvm-ranlib
+AR = llvm-ar
 else # CLANG
 CXX = $(GCC_PREFIX)g++$(DW2)
 CC = $(GCC_PREFIX)gcc$(DW2)
-endif # CLANG
-
 WINDRES = $(GCC_PREFIX)windres
 DLLTOOL = $(GCC_PREFIX)dlltool
 RANLIB = $(GCC_PREFIX)ranlib
 AR = $(GCC_PREFIX)ar
+endif # CLANG
 
 M4 = $(strip $(call os_name, $(TOOLS_PREFIX)m4)) -P -DFARBIT=$(DIRBIT) -DBUILD_TYPE=$(FARMANAGER_BUILD_TYPE) -DSCM_REVISION=$(FARMANAGER_SCM_REVISION) -DHOSTTYPE=$(HOST_TYPE)
 GAWK = $(strip $(call os_name, $(TOOLS_PREFIX)gawk))
-LGEN = $(WINE_CMD)$(strip $(call os_name, $(TOOLSDIR)lng.generator.exe))
+
+ifdef PYTHON
+ LGEN = $(strip $(call os_name, python $(FARDIR)../misc/lng/lng.generator.py))
+else
+ LGEN = $(WINE_CMD)$(strip $(call os_name, $(TOOLSDIR)lng.generator.exe))
+endif
 # Toolchain setup end
 
 # Output directory setup
@@ -176,8 +184,13 @@ CFLAGS += \
 ifeq ($(USE_LTO),1)
 CFLAGS += \
 	-flto \
+
+ifndef CLANG
+CFLAGS += \
 	-flto-odr-type-merging \
 
+endif
+
 endif # USE_LTO
 
 LNKFLAGS += \
@@ -212,12 +225,16 @@ LLD_FLAGS = \
 
 ifdef CLANG
 ifeq ($(DIRBIT), 32)
-CLANG_TARGET = i686-pc-windows-gnu
+CLANG_TARGET = i686-w64-mingw32
 else
-CLANG_TARGET = x86_64-pc-windows-gnu
+CLANG_TARGET = x86_64-w64-mingw32
 endif
 
 CLANG_FLAGS = \
+	--start-no-unused-arguments \
+	-rtlib=compiler-rt \
+	-unwindlib=libunwind \
+	--end-no-unused-arguments \
 	-target $(CLANG_TARGET) \
 	-Wno-unknown-warning-option \
 	-fms-extensions \

Of course, this also works for msys2. The CLANG_TARGET chagne is not necessary, but I changed it anyway, because it's what llvm-mingw wrappers use, and also what clang -dumpmachine outputs.

Also, I want to bring to your attention, that the upcoming version (18) of libc++ (can be tested with the pre-release version of llvm-mingw), implements the C++23 std::ranges::fold_* algorithms, but no __cpp_lib_ranges_fold is defined (at least no yet), so another check is needed to skip the local implementation of fold_left:

diff --git a/far/common/cpp.hpp b/far/common/cpp.hpp
index cbd012328..45beb6651 100644
--- a/far/common/cpp.hpp
+++ b/far/common/cpp.hpp
@@ -128,6 +128,7 @@ namespace std
 }
 #endif
 
+#if (__cplusplus < 202302L)
 #ifndef __cpp_lib_ranges_fold
 #include <functional>
 #include <iterator>
@@ -161,6 +162,7 @@ namespace std::ranges
 	inline constexpr fold_left_fn fold_left;
 }
 #endif
+#endif
 
 #ifndef __cpp_size_t_suffix
 

[alabuzhev]

@bitraid please feel free to create a PR.
What exactly are these changes for - compiling windows binaries on linux machines or something?
If so, it would be great if you could add a corresponding configuration here to make sure it remains in working condition as we go.

---

-CXX = clang++
+CXX = clang --driver-mode=g++ -stdlib=libc++

Specifying -stdlib=libc++ here explicitly would break the "clang with libstdc++" configuration. Perhaps we need to parametrize it somehow to keep both.

[bitraid]

Yes, exactly. It's for compiling windows programs on linux. I'll come up with something to address the stdlib issue, and add to github workflow.