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
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
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.
--Travis
On Wed, Dec 15, 2021 at 7:26 AM Travis Fisher <traviswfis...@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 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?
> --Travis
>
> On Tue, Dec 14, 2021 at 3:32 AM Travis Fisher <traviswfis...@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 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 read
>>
>> case $as_dir in #(((
>> '') as_dir=./ ;;
>> */) ;;
>> *) as_dir=$as_dir/ ;;
>> esac
>>
>> but instead reads
>>
>> case $as_dir in #(((
>> ''
>> as_dir=./ ;;
>> */) ;;
>> *) as_dir=$as_dir/ ;;
>> esac
>>
>> I 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) 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.
>> * 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, RANDPOISSON
>>
>> 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
>>
>> --Travis
>>
>>
>>
>>
>>
>>
>>
_______________________________________________
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
