Re: mostly successful windows build

To get the "make install" gnumeric running I have two broken bits of excelplugins that I've commented out.  One is a bit of asm code that doesn't compile for me and I don't really know what it is trying to do.  The other is the g_stat function which is clobbering the stack and causing a crash on startup.  After that gnumeric will run and do things like open .xls files.  

The broken bits of excelplugins I don't know how to solve yet:

$ git diff excelplugins.c
diff --git a/plugins/excelplugins/excelplugins.c b/plugins/excelplugins/excelplugins.c
index c21e16114..fae5e663e 100644
--- a/plugins/excelplugins/excelplugins.c
+++ b/plugins/excelplugins/excelplugins.c
@@ -969,7 +969,7 @@ scan_for_XLLs_and_register_functions (const gchar *dir_name)
                while ((d_name = g_dir_read_name (dir)) != NULL) {
                        if ( ! (strcmp (d_name, ".") == 0 || strcmp (d_name, "..") == 0)) {
                                full_entry_name = g_build_filename (dir_name, d_name, NULL);
-                               stat_success = g_stat (full_entry_name,&d_info);
+                               stat_success = -1; /* TWF KLUDGE g_stat (full_entry_name,&d_info); */
                                if (0 == stat_success) {
                                        if (S_ISDIR (d_info.st_mode)) {
                                                scan_for_XLLs_and_register_functions (full_entry_name);

$ git diff xlcall32_emulation.c
diff --git a/plugins/excelplugins/xlcall32_emulation.c b/plugins/excelplugins/xlcall32_emulation.c
index ede716d8f..ef775137a 100644
--- a/plugins/excelplugins/xlcall32_emulation.c
+++ b/plugins/excelplugins/xlcall32_emulation.c
@@ -82,7 +82,7 @@ int far pascal XLCallVer(void){
        return 1280;

-#ifdef WIN32
-asm (".section .drectve");
-asm (".ascii \"-export:Excel4v=Excel4v@16,XLCallVer=XLCallVer@0\"");
+//#ifdef WIN32
+//asm (".section .drectve");
+//asm (".ascii \"-export:Excel4v=Excel4v@16,XLCallVer=XLCallVer@0\"");

I also am having trouble running tests.  When I do "make check-TESTS" everything is failing.  The logs look like:

------------------------------------------------------------------------------- Check that statfuns.xls evaluates correctly.
| ** (C:/msys64/home/travi/gnumeric/src/.libs/ssconvert.exe:19696): WARNING **: 18:23:21.988: Unable to get registry key gnumeric\core\gui\screen\horizontaldpi because The system cannot find the file specified.
| ** (C:/msys64/home/travi/gnumeric/src/.libs/ssconvert.exe:19696): WARNING **: 18:23:21.988: Unable to get registry key gnumeric\core\defaultfont\name because The system cannot find the file specified.
| ** (C:/msys64/home/travi/gnumeric/src/.libs/ssconvert.exe:19696): WARNING **: 18:23:21.988: Unable to get registry key gnumeric\core\defaultfont\size because The system cannot find the file specified.
| ** (C:/msys64/home/travi/gnumeric/src/.libs/ssconvert.exe:19696): WARNING **: 18:23:22.003: Unable to get registry key gnumeric\core\gui\screen\verticaldpi because The system cannot find the file specified.
| ** (C:/msys64/home/travi/gnumeric/src/.libs/ssconvert.exe:19696): WARNING **: 18:23:22.003: Unable to get registry key gnumeric\plugins\activate-newplugins because The system cannot find the file specified.
| E Unsupported file format for file "statfuns.xls"
Cannot open statfuns.csv: No such file or directory
FAIL (exit status: 2)

But I can load statfuns.xls in the gnumeric application okay, and if I use the installed ssconvert there are the warnings about missing registry keys but it will convert statfuns.xls to statfuns.csv.  

Any suggestions there?


On Wed, Dec 15, 2021 at 3:27 PM Travis Fisher <traviswfisher gmail com> wrote:
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:255

Investigating it seems the problem is the g_stat function is stomping on the stack.  According to there are different Windows functions it might use:

"On Windows the Microsoft C libraries have several variants of the stat struct and stat() 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.


On 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 :

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:] Error 1

If 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?

On 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-tools

The minor issues:
For both goffice and gnumeric there are similar syntax errors in the configure file generated by  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 read

  case $as_dir in #(((
    '') as_dir=./ ;;
    */) ;;
    *) as_dir=$as_dir/ ;;

but instead reads 

  case $as_dir in #(((
 as_dir=./ ;;
    */) ;;
    *) as_dir=$as_dir/ ;;

I don't know if the parenthesis somehow gets teleported hundreds of lines later?

There is a minor problem with the goffice docs which I fixed like this:

diff --git a/docs/reference/ b/docs/reference/
index 3278839c..1afb26c1 100644
--- a/docs/reference/
+++ b/docs/reference/
@@ -48,6 +48,10 @@ GTKDOC_LIBS = $(top_builddir)/goffice/ $(GOFFICE_

 include $(top_srcdir)/gtk-doc.make



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) as 

  int 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.
         * */
-       g_option_context_set_delocalize   (ocontext, FALSE);
+       //      g_option_context_set_delocalize   (ocontext, FALSE);

        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:


It 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]