Building for ARM

[rasa]

I patched Xbuild4Windows.yml to build on ARM64,
but am getting the error
../../../lib/stat-time.h:51:43: error: invalid use of undefined type ‘const struct _stati64’ at
https://github.com/rasa/nano-for-windows/actions/runs/4205780215/jobs/7298354041#step:8:2186

I thought the issue is in the curses code, but it builds fine for arm/arm64 via https://github.com/rasa/PDCursesMod/blob/master/.github/workflows/github_actions_build_windows.yml

Any ideas?

[okibcn]

hmmmm..... interesting.

The problem is in gnulib, maybe a link issue? An incompatibility with MinGW in ARM64 (most probably)?

I will dig into that.

[okibcn]

I know what's going on.

1. I remember a few weeks ago I wanted to release also an arm64 version of this, but MinGW doesn't support arm64 at this time. I wanted to experiment with this unofficial port of MinGW for all four architectures: armv7 (ARM), aarch64 (ARM64), i686 (X86), and x86_64 (X86-64).
2. If you look at your build log, you will see that PDCursesMod is compiled using the i686, while nano is using gcc. Obviously, it is a recipe for disaster.
3. PDCursesMod lib is available for arm64 because it is built in Windows using the MS toolchain.

So, going forward, I only see two routes to include arm64 in the mix:

• MSVC
• llvm-mingw

I prefer the second as I feel way more comfortable using Linux dev tools. This is why I used this Xcompiling toolchain to build for Windows. But , maybe it is time to fight against the problems of porting gnulib to MSVC....

Any thought?

[rasa]

Llvm sounds the way to go. Even if we get gnulib ported to MSVC, we then have to port nano.
Note that https://www.gnu.org/software/gnulib/manual/gnulib.html#Supported-Platforms claims that MSVC 14 (2015):
"is occasionally tested. Only “release” builds (compiler option ‘-MD’) are supported, not “debug” builds (compiler option ‘-MDd’)."
so the maintainers may be open to PRs.

[okibcn]

Well, I have good news.

LLVM-MinGW works better than expected. It requires some minimal changes in the PDCursesMod makefile and adding the Bcrypt lib to nano, but other than that it goes quite smooth. All the features work: mouse, full unicode, transparent background, etc.

The amd64 version works well here. I can even build the arm64 version, but I can't test it since I don't have any arm64 windows hardware..

[okibcn]

First experimental build using Clang-UCRT-LLVM-MinGW-ld.lld toolchain for the three platforms: win32, win64, and winarm64 is now available for download as a temporal beta here:
https://github.com/okibcn/nano-for-windows/suites/11065058319/artifacts/562702379

It would be nice having some testing in a Windows arm64 environment.

[rasa]

I tried to signup for a Windows VM, at least five or six times, on Chrome and Edge, but got nothing but error messages

and:

It appears many others have received these cryptic error messages.

[okibcn]

Any alternative?

[rasa]

Not sure. Perhaps a VM, though it might be only arm and not arm64.

[okibcn]

I have evolved the script and made some key improvements:

1. adding WoA deliverable
2. separate packages per hardware platform
3. simplified folder structure
4. deprecated the build number from the version number as it is not needed.

Now the deliverable assets would be:
nano-for-windows_amd64_v7.2-13.zip
nano-for-windows_win32_v7.2-13.zip
nano-for-windows_win64_v7.2-13.zip
hashes.txt

Each package is about 350KB.

[okibcn]

I am exploring a estrange behavior when building in a container vs in WSL. The differences are way more obvious for the x86_64 than for other platforms.

• The WSL version takes the container version and is created importing the tar export from docker.
• The Container version is then run in docker running on the same edge 3.17. This is to make them both as similar as possible.

The problem is that the output is different. Using the same packages, and removing /mnt/* entries from the path of the WSL distro should return the same configuration, isn't it? Well, they don't. After running ./configure the situation is different:

This is the diff result from container to the WSL version of config.h:

-#define NEED_PRINTF_FLAG_GROUPING 1
+/* #undef NEED_PRINTF_FLAG_GROUPING */

 /* Define if the vasnprintf implementation needs special code for the '-'
    flag. */
@@ -1443,11 +1443,11 @@

 /* Define if the vasnprintf implementation needs special code for the 0 flag.
    */
-#define NEED_PRINTF_FLAG_ZERO 1
+/* #undef NEED_PRINTF_FLAG_ZERO */

 /* Define if the vasnprintf implementation needs special code for infinite
    'double' arguments. */
-#define NEED_PRINTF_INFINITE_DOUBLE 1
+/* #undef NEED_PRINTF_INFINITE_DOUBLE */

 /* Define if the vasnprintf implementation needs special code for infinite
    'long double' arguments. */
@@ -1459,7 +1459,7 @@

 /* Define if the vasnprintf implementation needs special code for supporting
    large precisions without arbitrary bounds. */
-#define NEED_PRINTF_UNBOUNDED_PRECISION 1
+/* #undef NEED_PRINTF_UNBOUNDED_PRECISION */

 /* Define this if you need the _XOPEN_SOURCE_EXTENDED macro for color support.
    */
@@ -1793,7 +1793,7 @@

 /* Define to rpl_ if the getopt replacement functions and variables should be
    used. */
-#define __GETOPT_PREFIX rpl_
+/* #undef __GETOPT_PREFIX */

 /* Define to 1 on platforms where this makes time_t a 64-bit type. */
 /* #undef __MINGW_USE_VC2005_COMPAT */

Makefile is also different. This is the diff result from container to the WSL version:

--- nanoc/Makefile
+++ nanow/Makefile
@@ -354,8 +354,8 @@
 FLOAT_H =
 FNMATCH_H = fnmatch.h
 GETLOGIN_LIB = -ladvapi32
-GETOPT_CDEFS_H = getopt-cdefs.h
-GETOPT_H = getopt.h
+GETOPT_CDEFS_H =
+GETOPT_H =
 GETRANDOM_LIB = -lbcrypt
 GETTEXT_MACRO_VERSION = 0.18
 GLOB_H = glob.h
@@ -759,7 +759,7 @@
 GL_GNULIB_TRUNCL = 0
 GL_GNULIB_TTYNAME_R = 0
 GL_GNULIB_TZSET = 0
-GL_GNULIB_UNISTD_H_GETOPT = 1
+GL_GNULIB_UNISTD_H_GETOPT = 0
 GL_GNULIB_UNISTD_H_NONBLOCKING = 0
 GL_GNULIB_UNISTD_H_SIGPIPE = 0
 GL_GNULIB_UNLINK = 0
@@ -1140,7 +1140,7 @@
 HAVE_SYMLINK = 1
 HAVE_SYMLINKAT = 1
 HAVE_SYS_BITYPES_H = 0
-HAVE_SYS_CDEFS_H = 1
+HAVE_SYS_CDEFS_H =
 HAVE_SYS_INTTYPES_H = 0
 HAVE_SYS_LOADAVG_H = 0
 HAVE_SYS_PARAM_H = 0
@@ -1425,9 +1425,9 @@
 REPLACE_FREE = 1
 REPLACE_FREELOCALE = 0
 REPLACE_FREOPEN = 0
-REPLACE_FREXP = 1
+REPLACE_FREXP = 0
 REPLACE_FREXPF = 0
-REPLACE_FREXPL = 1
+REPLACE_FREXPL = 0
 REPLACE_FSEEK = 0
 REPLACE_FSEEKO = 0
 REPLACE_FSTAT = 1
@@ -1699,9 +1699,9 @@
 docdir = ${datarootdir}/doc/${PACKAGE_TARNAME}
 dvidir = ${docdir}
 exec_prefix = ${prefix}
-gl_LIBOBJDEPS =  ./$(DEPDIR)/asnprintf.Po ./$(DEPDIR)/fnmatch.Po ./$(DEPDIR)/frexp.Po ./$(DEPDIR)/frexpl.Po ./$(DEPDIR)/malloc.Po ./$(DEPDIR)/mbsrtowcs-state.Po ./$(DEPDIR)/printf-args.Po ./$(DEPDIR)/printf-parse.Po ./$(DEPDIR)/realloc.Po ./$(DEPDIR)/snprintf.Po ./$(DEPDIR)/stat-w32.Po ./$(DEPDIR)/strcasestr.Po ./$(DEPDIR)/vasnprintf.Po ./$(DEPDIR)/vsnprintf.Po
-gl_LIBOBJS =  asnprintf.o fnmatch.o frexp.o frexpl.o malloc.o mbsrtowcs-state.o printf-args.o printf-parse.o realloc.o snprintf.o stat-w32.o strcasestr.o vasnprintf.o vsnprintf.o
-gl_LTLIBOBJS =  asnprintf.lo fnmatch.lo frexp.lo frexpl.lo malloc.lo mbsrtowcs-state.lo printf-args.lo printf-parse.lo realloc.lo snprintf.lo stat-w32.lo strcasestr.lo vasnprintf.lo vsnprintf.lo
+gl_LIBOBJDEPS =  ./$(DEPDIR)/asnprintf.Po ./$(DEPDIR)/fnmatch.Po ./$(DEPDIR)/malloc.Po ./$(DEPDIR)/mbsrtowcs-state.Po ./$(DEPDIR)/printf-args.Po ./$(DEPDIR)/printf-parse.Po ./$(DEPDIR)/realloc.Po ./$(DEPDIR)/snprintf.Po ./$(DEPDIR)/stat-w32.Po ./$(DEPDIR)/strcasestr.Po ./$(DEPDIR)/vasnprintf.Po ./$(DEPDIR)/vsnprintf.Po
+gl_LIBOBJS =  asnprintf.o fnmatch.o malloc.o mbsrtowcs-state.o printf-args.o printf-parse.o realloc.o snprintf.o stat-w32.o strcasestr.o vasnprintf.o vsnprintf.o
+gl_LTLIBOBJS =  asnprintf.lo fnmatch.lo malloc.lo mbsrtowcs-state.lo printf-args.lo printf-parse.lo realloc.lo snprintf.lo stat-w32.lo strcasestr.lo vasnprintf.lo vsnprintf.lo
 gltests_LIBOBJDEPS =
 gltests_LIBOBJS =
 gltests_LTLIBOBJS =

Obviously, the extra requirements for the containerized version require extra code. The result is a 2KB bytes less code for the WSL version. The question is, why do those tests fail during the configuration process in the container and not in WSL ????

[okibcn]

I got my answer.

1. the ./configure process creates executable binaries for testing each feature.
2. Some features are tested just by successful compiling. However, some of them require the execution of the test binary and probing of its output.
3. For cross-compiling, the configure script assumes the features requiring those complete tests with execution are not supported since they can't be tested.
4. However, since WSL interop capabilities allow any windows EXE binary to be executed from within any distro, it can successfully pass all the tests for Windows EXE files, including those requiring execution.
5. Since WSL interop is not available from within a container inside a WSL linux distro, then that is the difference.

This can be overcome in two ways:
A. By knowing the answer and patching the config file after it has been generated (current implementation in my test workflow).
B. By installing wine in the container, adding this way the capability to pass the EXE file tests within any Linux, even containerized versions.

[okibcn]

The pre-release with the heavily improved toolchain and the first version for ARM is in the release section.

https://github.com/okibcn/nano-for-windows/releases/tag/v7.2-13.1