mingw patches / how to build

[GitMensch]

I did not found the following information and wanted to drop it it here - you may close this issue, copy part of it to documentation, include the patches or whatever you like. This information is partially written from mind so it may not be complete, still should give a good starter.

Prerequistes (rough outline):

• get crosstool-ng, rename it (possibly to CT-NG and place it directly under X: [we want to circumvent possible filename length issues])
• create a folder x:\mingw\bin
• download mingw-get.exe and place it there
• open cmd.exe, cd to this directory and do
  • mingw-get.exe list (this should auto-download the necessary package lists)
  • mingw-get.exe install gcc g++ autotools msys-libregex msys-wget msys-coreutils-ext msys-patch msys-help2man (this should get you at least most of the necessary tools)
• possibly: {patch MinGW's errno.h](https://osdn.net/projects/mingw/ticket/40848) - I don't know if this is necessary with crosstool-ng, but I did that before when building recent binutils manually, so adding this for completeness here
• unpack current ncurses for mingw32 from ftp://ftp.invisible-island.net/ncurses/win32/ to x:\mingw
• start msys [found at x:\mingw\msys\1.0\msys.bat] and then close it
• edit x:\mingw\msys\1.0\etc\fstab, adding a new entry for CT-NG (for example `X:/CT-NG /crosstool-ng)
• start msys [found at x:\mingw\msys\1.0\msys.bat] and then close it
• get bison and flex (possibly current one from winbisonflex) and ensure you have it in PATH with their plain names (for example by creating a symlink to the long name)
• follow the standard configure procedure (you may see additional missing tools in that step), taking care of the special ncurses include, via CPPFLAGS see #1403

Patches:

• uname, (ideally use gnulib in the first place in this repo or better upstream; otherwise...)
  • add missing sys/uname.h and lib_uname.c from a gnulib created environment
  • hack the generated kconfig/Makefile:
    • add lib_uname.$(OBJEXT) to am_conf_OBJECTS, am_mconf_OBJECTS, am_nconf_OBJECTS
    • add -lregex -lws2_32 to conf_LDADD, mconf_LDADD, nconf_LDADD (or cleaner: define a new WIN_LIBS with those two and reference this in the three places (then config.in could use a conditional to have it defined as empty or with that content)
• source changes, would likely be cleaner using gnulib

#./konfig/nconf.c, line 368, didn't want to search for a replacement, gnulib likely has one
+#ifdef _WIN32
+static char *strcasestr(const char *str, const char *pattern) {
+    size_t i;
+
+    if (!*pattern)
+        return (char*)str;
+
+    for (; *str; str++) {
+        if (toupper((unsigned char)*str) == toupper((unsigned char)*pattern)) {
+            for (i = 1;; i++) {
+                if (!pattern[i])
+                    return (char*)str;
+                if (toupper((unsigned char)str[i]) != toupper((unsigned char)pattern[i]))
+                    break;
+            }
+        }
+    }
+    return NULL;
+}
+
 static void print_function_line(void)
#./konfig/confdata.c, line 15, didn't want to search for a nicer version replacement, gnulib likely has one
 #include <unistd.h>

+#ifdef _WIN32
+#define mkdir(p,m) mkdir(p)
+#endif
+
 #include "lkc.h"

Then run make and use crosstool-ng per standard instructions.

Note: depending on the way you've got crosstool-ng and where you've unpacked it first you may have to manually rename some of the patch files (make will in this case say "don't know how to make 0011-xyz-long-name.patch` and the file name is shortened, in that case just rename via Explorer to the requested name and you should be fine).

Note: for the current curses version you also need a matching libgcc_s_sjlj-1.dll, if you don't have that, you may want to try this one. When using ct-ng: always unset TERM, otherwise it won't work from within msys.

[mingwandroid]

MinGW as a project is all but dead.

Any reason not to use mingw-w64?

[alfred-lijun]

thanks very much!

[GitMensch]

MinGW as a project is all but dead.

Nope, they still work on it (just with a pace that is much slower than mingw-w64), see its mailing list and the "recent" release of GCC currently at 9.2 - later than the post which claims it is dead ;-)

Any reason not to use mingw-w64?

One reason would be the often lesser dependency and support back to Win9x while mingw-w64 seems to be depending on Windows Server 2008 / Win Vista and its packaging within MSYS2 needs Windows Server 2008 R2 / Windows 7 (cygwin deprecated Windows Server 2008, too).