After a bit more hacking I got the build to complete to where I can run "make install". Unlike the simple gnumeric.exe in the src directory, the one that gets installed crashes on startup. The stack trace looks like :Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007fff16c493ea in go_plugin_loader_module_load_base (loader=0x2aab36930c0, err=0x61ba2ca2) at app/go-plugin-loader-module.c:154
154 if (*err != NULL) {
(gdb) bt
#0 0x00007fff16c493ea in go_plugin_loader_module_load_base (loader=0x2aab36930c0, err=0x61ba2ca2) at app/go-plugin-loader-module.c:154
#1 0x00007fff16c47afe in go_plugin_loader_load_base (loader=0x2aab36930c0, err=0xab645ff3e0) at app/go-plugin-loader.c:96
#2 0x00007fff16c45bbd in go_plugin_load_base (plugin=0x2aab35617e0, ret_error=0xab645ff488) at app/go-plugin.c:1197
#3 0x00007fff16c469ce in go_plugin_db_activate_plugin_list (ret_error=0xab645ff500, plugins=<optimized out>) at app/go-plugin.c:1493
#4 go_plugin_db_activate_plugin_list (plugins=<optimized out>, ret_error=0xab645ff500) at app/go-plugin.c:1488
#5 0x00007fff16c4746c in go_plugins_init (context=0x2aab30e2290, known_states=<optimized out>, active_plugins=<optimized out>, plugin_dirs=<optimized out>, activate_new_plugins=1,
default_loader_type=2932175838160) at app/go-plugin.c:1869
#6 0x00007fff1512cb25 in gnm_plugins_init (context=0x2aab30e2290) at C:/msys64/home/travi/gnumeric/src/gnm-plugin.c:1029
#7 0x00007ff702283f05 in main (argc=<optimized out>, argv=<optimized out>) at C:/msys64/home/travi/gnumeric/src/main-application.c:255Investigating it seems the problem is the g_stat function is stomping on the stack. According to https://people.gnome.org/~ryanl/glib-docs/glib-File-Utilities.html#g-stat there are different Windows functions it might use:"On Windows the Microsoft C libraries have several variants of the stat struct andstat()function with names like "_stat", "_stat32", "_stat32i64" and "_stat64i32". The one used here is for 32-bit code the one with 32-bit size and time fields, specifically called "_stat32".In Microsoft's compiler, by default "struct stat" means one with 64-bit time fields while in MinGW "struct stat" is the legacy one with 32-bit fields. To hopefully clear up this messs, the gstdio.h header defines a type GStatBuf which is the appropriate struct type depending on the platform and/or compiler being used."
So something with this mess is broken on the MINGW UCRT64 build, I guess more likely on the GLib side than the gnumeric/goffice side though that isn't all the way clear yet.--TravisOn Wed, Dec 15, 2021 at 7:26 AM Travis Fisher <traviswfisher gmail com> wrote:The error building excel plugin is a complete mystery to me. I am getting :CCLD excel.la
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ms-excel-read.o: in function `excel_set_xf':
C:\msys64\home\travi\gnumeric\plugins\excel/ms-excel-read.c:2312: undefined reference to `sheet_style_apply_border'
collect2.exe: error: ld returned 1 exit status
make[4]: *** [Makefile:617: excel.la] Error 1If I remark out the line in ms-excel-read.c that calls sheet_style_apply_border then the build succeeds. But I don't see any problem with how sheet_style_apply_border is defined and I don't see why anything is different about this particular function or its usage in the MINGW UCRT build compared to a linux target.Any ideas?--TravisOn Tue, Dec 14, 2021 at 3:32 AM Travis Fisher <traviswfisher gmail com> wrote:I made an effort to build gnumeric under MSYS2 MINGW on Windows 10. There were only a few minor issues to getting a mostly working application. I thought I would send a report here in case others want to follow.I am using the UCRT64 environment. That links with the more standards-compliant UCRT runtime which may be an easier target than the older MSVCRT runtime.I found MSYS2 packaged builds were available for everything required except goffice and gnumeric which I built from source (git latest as of a few days ago).An incomplete list of packages I installed:pacman -S mingw-w64-ucrt-x86_64-gtk-doc
pacman -S mingw-w64-ucrt-x86_64-gtk3
pacman -S mingw-w64-ucrt-x86_64-libgsf
pacman -S mingw-w64-ucrt-x86_64-libxml2
pacman -S mingw-w64-ucrt-x86_64-gettext
pacman -S mingw-w64-ucrt-x86_64-yelp-toolsThe minor issues:For both goffice and gnumeric there are similar syntax errors in the configure file generated by autogen.sh. I haven't tried to understand the generation process; I fixed the configure file by hand.For goffice there is a missing right parenthesis and extra newline in a case statement around line 6448 and a spurious right parenthesis on line ~7346. The case statement should readcase $as_dir in #(((
'') as_dir=./ ;;
*/) ;;
*) as_dir=$as_dir/ ;;
esacbut instead readscase $as_dir in #(((
''
as_dir=./ ;;
*/) ;;
*) as_dir=$as_dir/ ;;
esacI don't know if the parenthesis somehow gets teleported hundreds of lines later?There is a minor problem with the goffice docs Makefile.am which I fixed like this:diff --git a/docs/reference/Makefile.am b/docs/reference/Makefile.am
index 3278839c..1afb26c1 100644
--- a/docs/reference/Makefile.am
+++ b/docs/reference/Makefile.am
@@ -48,6 +48,10 @@ GTKDOC_LIBS = $(top_builddir)/goffice/libgoffice-@GOFFICE_API_VER@.la $(GOFFICE_
include $(top_srcdir)/gtk-doc.make
+EXTRA_DIST =
+
+CLEANFILES =
+
EXTRA_DIST += version.xml.in
CLEANFILES += \Then there is a problem mentioned on this list some months ago about windows missing the isnanl function. Morten mentioned it was possible to just disable long double support by a build flag. I supplied my own implementation in the 3 files affected (goffice/math/go-R.c, goffice/math/go-math.c, goffice/math/go-quad.c) asint isnanl(long double x) { return (!((x>=0)||(x<=0))); }This is a bodge; the right solution I think is that autotools can supply this function on platforms it is missing. Again I haven't learned autotools so I just hacked it up by hand.There is another problem that configure notes about missing rand functionality that is probably related to random numbers not working in the gnumeric build (see below).After make and make install of goffice, I moved on to gnumeric. There is the same problem of the teleporting parenthesis in the configure file. Then there is an issue again mentioned on this list months ago where some workaround for windows command line localization is broken and doesn't compile (or glib is broken I guess?). Anyway remarking that out gets us a build that runs but I guess will be broken somehow in processing command line options:diff --git a/src/main-application.c b/src/main-application.c
index ae8beaccd..865edd2c8 100644
--- a/src/main-application.c
+++ b/src/main-application.c
@@ -114,7 +114,7 @@ gnumeric_arg_parse (int argc, char **argv)
#if defined(G_OS_WIN32)
/* we have already translated to utf8, do not do it again.
* http://bugzilla.gnome.org/show_bug.cgi?id=361321 */
- g_option_context_set_delocalize (ocontext, FALSE);
+ // g_option_context_set_delocalize (ocontext, FALSE);
#endif
g_option_context_add_group (ocontext, gtk_get_option_group (TRUE));The only other bit I had to add was in the CFLAGS of the gnumeric makefile -fcommon. This is I think needed on other platforms with latest gcc as well, as gcc changed the default from -fno-common to -fcommon.I get a gnumeric.exe that runs and looks very nice. I only tried simple things so far. Running sstest.exe there are failures from test_random:SUMMARY: FAIL for RAND, RANDUNIFORM, RANDBETA, RANDCAUCHY, RANDCHISQ, RANDEXP, RANDFDIST, RANDGAMMA, RANDLOG, RANDLOGNORM, RANDNORM, RANDSNORM, RANDTDIST, RANDWEIBULL, RANDRAYLEIGH, RANDBERNOULLI, RANDBETWEEN, RANDBINOM, RANDDISCRETE, RANDGEOM, RANDHYPERG, RANDNEGBINOM, RANDPOISSONIt looks like all the random values are generated as zero.There were also build failures for some other minor executable which I didn't chase yet; I was excited to see gnumeric.exe come out :-).This failure I haven't looked at yet:C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ms-excel-read.o: in function `excel_set_xf':
C:\msys64\home\travi\gnumeric\plugins\excel/ms-excel-read.c:2312: undefined reference to `sheet_style_apply_border'
collect2.exe: error: ld returned 1 exit status--Travis