Re: mostly successful windows build
Travis Fisher via gnumeric-list <[email protected]> Wed, 15 Dec 2021 18:43:02 -0500
| Newsgroups | gmane.comp.gnome.apps.gnumeric |
|---|---|
| Message-ID | <CAPdQ-ZedDo9x4eCRcj8K_yad3+vkwyjacKUdVfjrwOJHy3OCJA@mail.gmail.com> |
--===============1039323247550198319==
Content-Type: multipart/alternative; boundary="000000000000769cbf05d337de51"
--000000000000769cbf05d337de51
Content-Type: text/plain; charset="UTF-8"
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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
--000000000000769cbf05d337de51
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To get the "make install" gnumeric running I hav=
e two broken bits of excelplugins that I've commented out.=C2=A0 One is=
a bit of asm code that doesn't compile for me and I don't really k=
now what it is trying to do.=C2=A0 The other is the g_stat function which i=
s clobbering the stack and causing a crash on startup.=C2=A0 After that gnu=
meric will run and do things like open .xls files.=C2=A0=C2=A0<div><br></di=
v><div>The broken bits of excelplugins=C2=A0I don't know how to solve y=
et:</div><div><br></div><div>$ git diff excelplugins.c<br>diff --git a/plug=
ins/excelplugins/excelplugins.c b/plugins/excelplugins/excelplugins.c<br>in=
dex c21e16114..fae5e663e 100644<br>--- a/plugins/excelplugins/excelplugins.=
c<br>+++ b/plugins/excelplugins/excelplugins.c<br>@@ -969,7 +969,7 @@ scan_=
for_XLLs_and_register_functions (const gchar *dir_name)<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 while ((d_name =3D g_dir_read_nam=
e (dir)) !=3D NULL) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( ! (strcmp (d_name, ".") =
=3D=3D 0 || strcmp (d_name, "..") =3D=3D 0)) {<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 full_entry_name =3D g_build_filename (dir_name, d_=
name, NULL);<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stat_success =3D g_stat (f=
ull_entry_name,&d_info);<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stat_succes=
s =3D -1; /* TWF KLUDGE g_stat (full_entry_name,&d_info); */<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (0 =3D=3D stat_success) {<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (S_ISDIR (d_info=
.st_mode)) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scan_for_XLLs_and_register_functions (fu=
ll_entry_name);<br><br>$ git diff xlcall32_emulation.c<br>diff --git a/plug=
ins/excelplugins/xlcall32_emulation.c b/plugins/excelplugins/xlcall32_emula=
tion.c<br>index ede716d8f..ef775137a 100644<br>--- a/plugins/excelplugins/x=
lcall32_emulation.c<br>+++ b/plugins/excelplugins/xlcall32_emulation.c<br>@=
@ -82,7 +82,7 @@ int far pascal XLCallVer(void){<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return 1280;<br>=C2=A0}<br><br>-#ifdef WIN32<br>-asm (".section=
.drectve");<br>-asm (".ascii \"-export:Excel4v=3DExcel4v@16=
,XLCallVer=3DXLCallVer@0\"");<br>-#endif<br>+//#ifdef WIN32<br>+/=
/asm (".section .drectve");<br>+//asm (".ascii \"-expor=
t:Excel4v=3DExcel4v@16,XLCallVer=3DXLCallVer@0\"");<br>+//#endif<=
br></div><div><br></div><div>I also am having trouble running tests.=C2=A0 =
When I do "make check-TESTS" everything is failing.=C2=A0 The log=
s look like:</div><div><br></div><div>cat t1000-statfuns.pl.log<br>--------=
-----------------------------------------------------------------------<br>=
<a href=3D"http://t1000-statfuns.pl">t1000-statfuns.pl</a>: Check that stat=
funs.xls evaluates correctly.<br>|<br>| ** (C:/msys64/home/travi/gnumeric/s=
rc/.libs/ssconvert.exe:19696): WARNING **: 18:23:21.988: Unable to get regi=
stry key gnumeric\core\gui\screen\horizontaldpi because The system cannot f=
ind the file specified.<br>|<br>|<br>| ** (C:/msys64/home/travi/gnumeric/sr=
c/.libs/ssconvert.exe:19696): WARNING **: 18:23:21.988: Unable to get regis=
try key gnumeric\core\defaultfont\name because The system cannot find the f=
ile specified.<br>|<br>|<br>| ** (C:/msys64/home/travi/gnumeric/src/.libs/s=
sconvert.exe:19696): WARNING **: 18:23:21.988: Unable to get registry key g=
numeric\core\defaultfont\size because The system cannot find the file speci=
fied.<br>|<br>|<br>| ** (C:/msys64/home/travi/gnumeric/src/.libs/ssconvert.=
exe:19696): WARNING **: 18:23:22.003: Unable to get registry key gnumeric\c=
ore\gui\screen\verticaldpi because The system cannot find the file specifie=
d.<br>|<br>|<br>| ** (C:/msys64/home/travi/gnumeric/src/.libs/ssconvert.exe=
:19696): WARNING **: 18:23:22.003: Unable to get registry key gnumeric\plug=
ins\activate-newplugins because The system cannot find the file specified.<=
br>|<br>| E Unsupported file format for file "statfuns.xls"<br>Ca=
nnot open statfuns.csv: No such file or directory<br>FAIL <a href=3D"http:/=
/t1000-statfuns.pl">t1000-statfuns.pl</a> (exit status: 2)<br></div><div><b=
r></div><div>But I can load statfuns.xls in the gnumeric application okay, =
and if I use the installed ssconvert there are the warnings about missing r=
egistry keys but it will convert statfuns.xls to statfuns.csv.=C2=A0=C2=A0<=
/div><div><br></div><div>Any suggestions there?</div><div><br></div><div>Th=
anks,</div><div>--Travis</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Dec 15, 2021 at 3:27 PM Travis Fisher=
<<a href=3D"mailto:[email protected]">[email protected]</a>=
> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
dir=3D"ltr">After a bit more hacking I got the build to complete to where =
I can run "make install".=C2=A0 Unlike the simple gnumeric.exe in=
the src directory, the one that gets installed crashes on startup.=C2=A0 T=
he stack trace looks like :<div><br></div><div>Thread 1 received signal SIG=
SEGV, Segmentation fault.<br>0x00007fff16c493ea in go_plugin_loader_module_=
load_base (loader=3D0x2aab36930c0, err=3D0x61ba2ca2) at app/go-plugin-loade=
r-module.c:154<br>154 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 if (*err !=3D NULL) {<br>(gdb) bt<br>#0 =C2=A00x00007fff1=
6c493ea in go_plugin_loader_module_load_base (loader=3D0x2aab36930c0, err=
=3D0x61ba2ca2) at app/go-plugin-loader-module.c:154<br>#1 =C2=A00x00007fff1=
6c47afe in go_plugin_loader_load_base (loader=3D0x2aab36930c0, err=3D0xab64=
5ff3e0) at app/go-plugin-loader.c:96<br>#2 =C2=A00x00007fff16c45bbd in go_p=
lugin_load_base (plugin=3D0x2aab35617e0, ret_error=3D0xab645ff488) at app/g=
o-plugin.c:1197<br>#3 =C2=A00x00007fff16c469ce in go_plugin_db_activate_plu=
gin_list (ret_error=3D0xab645ff500, plugins=3D<optimized out>) at app=
/go-plugin.c:1493<br>#4 =C2=A0go_plugin_db_activate_plugin_list (plugins=3D=
<optimized out>, ret_error=3D0xab645ff500) at app/go-plugin.c:1488<br=
>#5 =C2=A00x00007fff16c4746c in go_plugins_init (context=3D0x2aab30e2290, k=
nown_states=3D<optimized out>, active_plugins=3D<optimized out>=
, plugin_dirs=3D<optimized out>, activate_new_plugins=3D1,<br>=C2=A0 =
=C2=A0 default_loader_type=3D2932175838160) at app/go-plugin.c:1869<br>#6 =
=C2=A00x00007fff1512cb25 in gnm_plugins_init (context=3D0x2aab30e2290) at C=
:/msys64/home/travi/gnumeric/src/gnm-plugin.c:1029<br>#7 =C2=A00x00007ff702=
283f05 in main (argc=3D<optimized out>, argv=3D<optimized out>)=
at C:/msys64/home/travi/gnumeric/src/main-application.c:255<br></div><div>=
<br></div><div>Investigating it seems the problem is the g_stat function is=
stomping on the stack.=C2=A0 According to=C2=A0<a href=3D"https://people.g=
nome.org/~ryanl/glib-docs/glib-File-Utilities.html#g-stat" target=3D"_blank=
">https://people.gnome.org/~ryanl/glib-docs/glib-File-Utilities.html#g-stat=
</a> there are different Windows functions it might use:</div><div><br></di=
v><div>"<span style=3D"color:rgb(0,0,0);font-family:"Times New Ro=
man";font-size:medium">On Windows the Microsoft C libraries have sever=
al variants of the</span><span style=3D"color:rgb(0,0,0);font-family:"=
Times New Roman";font-size:medium">=C2=A0</span><span style=3D"color:r=
gb(0,0,0);font-family:"Times New Roman";font-size:medium">stat</s=
pan><span style=3D"color:rgb(0,0,0);font-family:"Times New Roman"=
;font-size:medium">=C2=A0</span><span style=3D"color:rgb(0,0,0);font-family=
:"Times New Roman";font-size:medium">struct and</span><span style=
=3D"color:rgb(0,0,0);font-family:"Times New Roman";font-size:medi=
um">=C2=A0</span><code style=3D"color:rgb(0,0,0)">stat()</code><span style=
=3D"color:rgb(0,0,0);font-family:"Times New Roman";font-size:medi=
um">=C2=A0</span><span style=3D"color:rgb(0,0,0);font-family:"Times Ne=
w Roman";font-size:medium">function with names like "_stat",=
"_stat32", "_stat32i64" and "_stat64i32". Th=
e one used here is for 32-bit code the one with 32-bit size and time fields=
, specifically called "_stat32".</span></div><p style=3D"color:rg=
b(0,0,0);font-family:"Times New Roman";font-size:medium">In Micro=
soft's compiler, by default "struct stat" means one with 64-b=
it time fields while in MinGW "struct stat" is the legacy one wit=
h 32-bit fields. To hopefully clear up this messs, the gstdio.h header defi=
nes a type GStatBuf which is the appropriate struct type depending on the p=
latform and/or compiler being used."</p>So something with this mess is=
broken on the MINGW UCRT64 build,=C2=A0I guess more likely on the GLib sid=
e than the gnumeric/goffice side though that isn't all the way clear ye=
t.<div><br></div><div>--Travis<br><div><br></div></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 15, 2021=
at 7:26 AM Travis Fisher <<a href=3D"mailto:[email protected]" ta=
rget=3D"_blank">[email protected]</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">The error building =
excel plugin is a complete mystery to me.=C2=A0 =C2=A0I am getting :<div><b=
r></div><div>=C2=A0 CCLD =C2=A0 =C2=A0 <a href=3D"http://excel.la" target=
=3D"_blank">excel.la</a><br>C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-ming=
w32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ms-excel-read.o=
: in function `excel_set_xf':<br>C:\msys64\home\travi\gnumeric\plugins\=
excel/ms-excel-read.c:2312: undefined reference to `sheet_style_apply_borde=
r'<br>collect2.exe: error: ld returned 1 exit status<br>make[4]: *** [M=
akefile:617: <a href=3D"http://excel.la" target=3D"_blank">excel.la</a>] Er=
ror 1<br></div><div><br></div><div>If I remark out the line in ms-excel-rea=
d.c that calls sheet_style_apply_border then the build succeeds.=C2=A0 But =
I don't see any problem with how sheet_style_apply_border is defined an=
d 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.=C2=A0=C2=
=A0</div><div><br></div><div>Any ideas?</div><div>--Travis</div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec=
14, 2021 at 3:32 AM Travis Fisher <<a href=3D"mailto:traviswfisher@gmai=
l.com" target=3D"_blank">[email protected]</a>> wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I made an =
effort to build gnumeric under MSYS2 MINGW on Windows 10.=C2=A0 There were =
only a few minor issues to getting a mostly working=C2=A0application.=C2=A0=
I thought I would send a report here in case others want to follow.<div><b=
r></div><div>I am using the UCRT64 environment.=C2=A0 That links with the m=
ore standards-compliant UCRT runtime which may be an easier target than the=
older MSVCRT runtime.</div><div><br></div><div>I found MSYS2 packaged buil=
ds were available for everything required except goffice and gnumeric which=
I built from source (git latest as of a few days ago).</div><div><br></div=
><div>An incomplete list of packages I installed:</div><div>=C2=A0 pacman -=
S mingw-w64-ucrt-x86_64-gtk-doc<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-g=
tk3<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-libgsf<br>=C2=A0 pacman -S mi=
ngw-w64-ucrt-x86_64-libxml2<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-gette=
xt<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-yelp-tools<br></div><div><br><=
/div><div>The minor issues:</div><div>For both goffice and gnumeric there a=
re similar syntax errors in the configure file generated by autogen.sh.=C2=
=A0 I haven't tried to understand the generation process; I fixed the c=
onfigure file by hand.</div><div><br></div><div>For goffice there is a miss=
ing right parenthesis=C2=A0and extra newline in a case statement around lin=
e=C2=A06448 and a spurious right parenthesis on line=C2=A0~7346.=C2=A0 The =
case statement should read</div><div><br></div><div>=C2=A0 case $as_dir in =
#(((<br>=C2=A0 =C2=A0 '') as_dir=3D./ ;;<br>=C2=A0 =C2=A0 */) ;;<br=
>=C2=A0 =C2=A0 *) as_dir=3D$as_dir/ ;;<br>=C2=A0 esac<br></div><div><br></d=
iv><div>but instead reads=C2=A0</div><div><br></div><div>=C2=A0 case $as_di=
r in #(((<br>=C2=A0 =C2=A0 ''<br>=C2=A0as_dir=3D./ ;;<br>=C2=A0 =C2=
=A0 */) ;;<br>=C2=A0 =C2=A0 *) as_dir=3D$as_dir/ ;;<br>=C2=A0 esac<br></div=
><div><br></div><div>I don't know if the parenthesis=C2=A0somehow gets =
teleported hundreds of lines later?</div><div><br></div><div>There is a min=
or problem with the goffice docs Makefile.am which I fixed like this:</div>=
<div><br></div><div>diff --git a/docs/reference/Makefile.am b/docs/referenc=
e/Makefile.am<br>index 3278839c..1afb26c1 100644<br>--- a/docs/reference/Ma=
kefile.am<br>+++ b/docs/reference/Makefile.am<br>@@ -48,6 +48,10 @@ GTKDOC_=
LIBS =3D $(top_builddir)/goffice/libgoffice-@[email protected] $(GOFFICE_=
<br><br>=C2=A0include $(top_srcdir)/gtk-doc.make<br><br>+EXTRA_DIST =3D<br>=
+<br>+CLEANFILES =3D<br>+<br>=C2=A0EXTRA_DIST +=3D <a href=3D"http://versio=
n.xml.in" target=3D"_blank">version.xml.in</a><br><br>=C2=A0CLEANFILES +=3D=
\<br></div><div><br></div><div>Then there is a problem mentioned on this l=
ist some months ago about windows missing the isnanl=C2=A0function.=C2=A0 M=
orten mentioned it was possible to just disable long double support by a bu=
ild flag.=C2=A0 I supplied my own implementation in the 3 files affected (g=
office/math/go-R.c, goffice/math/go-math.c, goffice/math/go-quad.c) as=C2=
=A0</div><div><br></div><div>=C2=A0 int isnanl(long double x) { return (!((=
x>=3D0)||(x<=3D0))); }</div><div><br></div><div>This is a bodge; the =
right solution I think is that autotools can supply this function on platfo=
rms it is missing.=C2=A0 Again I haven't learned autotools so I just ha=
cked it up by hand.</div><div><br></div><div>There is another problem that =
configure notes about missing rand functionality that is probably related t=
o random numbers not working in the gnumeric build (see below).</div><div><=
br></div><div>After make and make install of goffice, I moved on to gnumeri=
c.=C2=A0 There is the same problem of the teleporting parenthesis in the co=
nfigure file.=C2=A0 Then there is an issue again mentioned on this list mon=
ths ago where some workaround for windows command line localization is brok=
en and doesn't compile (or glib is broken I guess?).=C2=A0 Anyway remar=
king that out gets us a build that runs but I guess will be broken somehow =
in processing command line options:</div><div><br></div><div>diff --git a/s=
rc/main-application.c b/src/main-application.c<br>index ae8beaccd..865edd2c=
8 100644<br>--- a/src/main-application.c<br>+++ b/src/main-application.c<br=
>@@ -114,7 +114,7 @@ gnumeric_arg_parse (int argc, char **argv)<br>=C2=A0#i=
f defined(G_OS_WIN32)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* we have already tra=
nslated to utf8, do not do it again.<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=
<a href=3D"http://bugzilla.gnome.org/show_bug.cgi?id=3D361321" target=3D"_=
blank">http://bugzilla.gnome.org/show_bug.cgi?id=3D361321</a> */<br>- =C2=
=A0 =C2=A0 =C2=A0 g_option_context_set_delocalize =C2=A0 (ocontext, FALSE);=
<br>+ =C2=A0 =C2=A0 =C2=A0 // =C2=A0 =C2=A0 =C2=A0g_option_context_set_delo=
calize =C2=A0 (ocontext, FALSE);<br>=C2=A0#endif<br><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 g_option_context_add_group (ocontext, gtk_get_option_group (TRUE=
));<br></div><div><br></div><div>The only other bit I had to add was in the=
CFLAGS of the gnumeric makefile -fcommon.=C2=A0 This is I think needed on =
other platforms with latest gcc as well, as gcc changed the default from -f=
no-common to -fcommon.</div><div><br></div><div>I get a gnumeric.exe that r=
uns and looks very=C2=A0nice.=C2=A0 I only tried simple things so far.=C2=
=A0 Running sstest.exe there are failures from test_random:</div><div><br><=
/div><div>SUMMARY: FAIL for RAND, RANDUNIFORM, RANDBETA, RANDCAUCHY, RANDCH=
ISQ, RANDEXP, RANDFDIST, RANDGAMMA, RANDLOG, RANDLOGNORM, RANDNORM, RANDSNO=
RM, RANDTDIST, RANDWEIBULL, RANDRAYLEIGH, RANDBERNOULLI, RANDBETWEEN, RANDB=
INOM, RANDDISCRETE, RANDGEOM, RANDHYPERG, RANDNEGBINOM, RANDPOISSON<br></di=
v><div><br></div><div>It looks like all the random values are generated as =
zero.=C2=A0=C2=A0</div><div><br></div><div>There were also build failures f=
or some other minor executable which I didn't chase yet; I was excited =
to see gnumeric.exe come out :-).=C2=A0=C2=A0</div><div><br></div><div>This=
failure I haven't looked at yet:</div><div>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':<br>C:\msys64\home\tra=
vi\gnumeric\plugins\excel/ms-excel-read.c:2312: undefined reference to `she=
et_style_apply_border'<br>collect2.exe: error: ld returned 1 exit statu=
s<br></div><div><br></div><div>--Travis</div><div><br></div><div><br></div>=
<div><br></div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
--000000000000769cbf05d337de51--
--===============1039323247550198319==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
gnumeric-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnumeric-list
--===============1039323247550198319==--