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\"");
-#endif
+//#ifdef WIN32
+//asm (".section .drectve");
+//asm (".ascii \"-export:Excel4v=Excel4v@16,XLCallVer=XLCallVer@0\"");
+//#endif
I also am having trouble running tests. When I do "make check-TESTS"
everything is failing. The logs look like:
cat t1000-statfuns.pl.log
-------------------------------------------------------------------------------
t1000-statfuns.pl: 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 t1000-statfuns.pl (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?
Thanks,
--Travis
On Wed, Dec 15, 2021 at 3:27 PM Travis Fisher <[email protected]>
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
> 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 <[email protected]>
> 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 <[email protected]>
>> 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-@[email protected] $(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
[email protected]
https://mail.gnome.org/mailman/listinfo/gnumeric-list
