Re: mostly successful windows build
Travis Fisher via gnumeric-list <[email protected]> Wed, 15 Dec 2021 15:27:04 -0500
| Newsgroups | gmane.comp.gnome.apps.gnumeric |
|---|---|
| Message-ID | <CAPdQ-Zf=ciHdxzTETM2qXT-_=9ZAXDq_8czVp+_X4V-0nYCdFQ@mail.gmail.com> |
--===============7792554527040894627==
Content-Type: multipart/alternative; boundary="000000000000a52a2505d335219d"
--000000000000a52a2505d335219d
Content-Type: text/plain; charset="UTF-8"
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
>>
>>
>>
>>
>>
>>
>>
--000000000000a52a2505d335219d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">After a bit more hacking I got the build to complete to wh=
ere I can run "make install".=C2=A0 Unlike the simple gnumeric.ex=
e in the src directory, the one that gets installed crashes on startup.=C2=
=A0 The stack trace looks like :<div><br></div><div>Thread 1 received signa=
l SIGSEGV, Segmentation fault.<br>0x00007fff16c493ea in go_plugin_loader_mo=
dule_load_base (loader=3D0x2aab36930c0, err=3D0x61ba2ca2) at app/go-plugin-=
loader-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=A00x00007=
fff16c493ea in go_plugin_loader_module_load_base (loader=3D0x2aab36930c0, e=
rr=3D0x61ba2ca2) at app/go-plugin-loader-module.c:154<br>#1 =C2=A00x00007ff=
f16c47afe in go_plugin_loader_load_base (loader=3D0x2aab36930c0, err=3D0xab=
645ff3e0) at app/go-plugin-loader.c:96<br>#2 =C2=A00x00007fff16c45bbd in go=
_plugin_load_base (plugin=3D0x2aab35617e0, ret_error=3D0xab645ff488) at app=
/go-plugin.c:1197<br>#3 =C2=A00x00007fff16c469ce in go_plugin_db_activate_p=
lugin_list (ret_error=3D0xab645ff500, plugins=3D<optimized out>) at a=
pp/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=
, known_states=3D<optimized out>, active_plugins=3D<optimized out&=
gt;, 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) a=
t C:/msys64/home/travi/gnumeric/src/gnm-plugin.c:1029<br>#7 =C2=A00x00007ff=
702283f05 in main (argc=3D<optimized out>, argv=3D<optimized out&g=
t;) at C:/msys64/home/travi/gnumeric/src/main-application.c:255<br></div><d=
iv><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://peopl=
e.gnome.org/~ryanl/glib-docs/glib-File-Utilities.html#g-stat">https://peopl=
e.gnome.org/~ryanl/glib-docs/glib-File-Utilities.html#g-stat</a> there are =
different Windows functions it might use:</div><div><br></div><div>"<s=
pan style=3D"color:rgb(0,0,0);font-family:"Times New Roman";font-=
size:medium">On Windows the Microsoft C libraries have several variants of =
the</span><span style=3D"color:rgb(0,0,0);font-family:"Times New Roman=
";font-size:medium">=C2=A0</span><span class=3D"gmail-structname" styl=
e=3D"color:rgb(0,0,0);font-family:"Times New Roman";font-size:med=
ium">stat</span><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";fo=
nt-size:medium">=C2=A0</span><code class=3D"gmail-function" style=3D"color:=
rgb(0,0,0)">stat()</code><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">functio=
n with names like "_stat", "_stat32", "_stat32i64&=
quot; and "_stat64i32". The one used here is for 32-bit code the =
one with 32-bit size and time fields, specifically called "_stat32&quo=
t;.</span></div><p style=3D"color:rgb(0,0,0);font-family:"Times New Ro=
man";font-size:medium">In Microsoft's compiler, by default "s=
truct stat" means one with 64-bit time fields while in MinGW "str=
uct 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 approp=
riate struct type depending on the platform and/or compiler being used.&quo=
t;</p>So something with this mess is broken on the MINGW UCRT64 build,=C2=
=A0I guess more likely on the GLib side than the gnumeric/goffice side thou=
gh that isn't all the way clear yet.<div><br></div><div>--Travis<br cla=
ss=3D"gmail-Apple-interchange-newline"><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]=
m">[email protected]</a>> wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,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><br></div><div>=
=C2=A0 CCLD =C2=A0 =C2=A0 <a href=3D"http://excel.la" target=3D"_blank">exc=
el.la</a><br>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\travi\gnumeric\plugins\excel/ms-excel-=
read.c:2312: undefined reference to `sheet_style_apply_border'<br>colle=
ct2.exe: error: ld returned 1 exit status<br>make[4]: *** [Makefile:617: <a=
href=3D"http://excel.la" target=3D"_blank">excel.la</a>] Error 1<br></div>=
<div><br></div><div>If I remark out the line in ms-excel-read.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 and I don't s=
ee 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"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 14, 2021 at 3:32=
AM Travis Fisher <<a href=3D"mailto:[email protected]" target=3D"=
_blank">[email protected]</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(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 mino=
r issues to getting a mostly working=C2=A0application.=C2=A0 I thought I wo=
uld send a report here in case others want to follow.<div><br></div><div>I =
am using the UCRT64 environment.=C2=A0 That links with the more standards-c=
ompliant UCRT runtime which may be an easier target than the older MSVCRT r=
untime.</div><div><br></div><div>I found MSYS2 packaged builds were availab=
le for everything required except goffice and gnumeric which I built from s=
ource (git latest as of a few days ago).</div><div><br></div><div>An incomp=
lete list of packages I installed:</div><div>=C2=A0 pacman -S mingw-w64-ucr=
t-x86_64-gtk-doc<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-gtk3<br>=C2=A0 p=
acman -S mingw-w64-ucrt-x86_64-libgsf<br>=C2=A0 pacman -S mingw-w64-ucrt-x8=
6_64-libxml2<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-gettext<br>=C2=A0 pa=
cman -S mingw-w64-ucrt-x86_64-yelp-tools<br></div><div><br></div><div>The m=
inor issues:</div><div>For both goffice and gnumeric there are similar synt=
ax errors in the configure file generated by autogen.sh.=C2=A0 I haven'=
t tried to understand the generation process; I fixed the configure file by=
hand.</div><div><br></div><div>For goffice there is a missing right parent=
hesis=C2=A0and extra newline in a case statement around line=C2=A06448 and =
a spurious right parenthesis on line=C2=A0~7346.=C2=A0 The case statement s=
hould 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></div><div>but ins=
tead reads=C2=A0</div><div><br></div><div>=C2=A0 case $as_dir 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></d=
iv><div>I don't know if the parenthesis=C2=A0somehow gets teleported hu=
ndreds of lines later?</div><div><br></div><div>There is a minor problem wi=
th the goffice docs Makefile.am which I fixed like this:</div><div><br></di=
v><div>diff --git a/docs/reference/Makefile.am b/docs/reference/Makefile.am=
<br>index 3278839c..1afb26c1 100644<br>--- a/docs/reference/Makefile.am<br>=
+++ b/docs/reference/Makefile.am<br>@@ -48,6 +48,10 @@ GTKDOC_LIBS =3D $(to=
p_builddir)/goffice/libgoffice-@[email protected] $(GOFFICE_<br><br>=C2=
=A0include $(top_srcdir)/gtk-doc.make<br><br>+EXTRA_DIST =3D<br>+<br>+CLEAN=
FILES =3D<br>+<br>=C2=A0EXTRA_DIST +=3D <a href=3D"http://version.xml.in" t=
arget=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 list some mo=
nths ago about windows missing the isnanl=C2=A0function.=C2=A0 Morten menti=
oned it was possible to just disable long double support by a build flag.=
=C2=A0 I supplied my own implementation in the 3 files affected (goffice/ma=
th/go-R.c, goffice/math/go-math.c, goffice/math/go-quad.c) as=C2=A0</div><d=
iv><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 solut=
ion I think is that autotools can supply this function on platforms it is m=
issing.=C2=A0 Again I haven't learned autotools so I just hacked it up =
by hand.</div><div><br></div><div>There is another problem that configure n=
otes about missing rand functionality that is probably related to random nu=
mbers not working in the gnumeric build (see below).</div><div><br></div><d=
iv>After make and make install of goffice, I moved on to gnumeric.=C2=A0 Th=
ere is the same problem of the teleporting parenthesis in the configure fil=
e.=C2=A0 Then there is an issue again mentioned on this list months ago whe=
re some workaround for windows command line localization is broken and does=
n't compile (or glib is broken I guess?).=C2=A0 Anyway remarking that o=
ut gets us a build that runs but I guess will be broken somehow in processi=
ng command line options:</div><div><br></div><div>diff --git a/src/main-app=
lication.c b/src/main-application.c<br>index ae8beaccd..865edd2c8 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#if defined(G=
_OS_WIN32)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* we have already translated 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_delocalize =
=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 p=
latforms with latest gcc as well, as gcc changed the default from -fno-comm=
on to -fcommon.</div><div><br></div><div>I get a gnumeric.exe that runs and=
looks very=C2=A0nice.=C2=A0 I only tried simple things so far.=C2=A0 Runni=
ng sstest.exe there are failures from test_random:</div><div><br></div><div=
>SUMMARY: FAIL for RAND, RANDUNIFORM, RANDBETA, RANDCAUCHY, RANDCHISQ, RAND=
EXP, RANDFDIST, RANDGAMMA, RANDLOG, RANDLOGNORM, RANDNORM, RANDSNORM, RANDT=
DIST, RANDWEIBULL, RANDRAYLEIGH, RANDBERNOULLI, RANDBETWEEN, RANDBINOM, RAN=
DDISCRETE, RANDGEOM, RANDHYPERG, RANDNEGBINOM, RANDPOISSON<br></div><div><b=
r></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 for some =
other minor executable which I didn't chase yet; I was excited to see g=
numeric.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\travi\gnume=
ric\plugins\excel/ms-excel-read.c:2312: undefined reference to `sheet_style=
_apply_border'<br>collect2.exe: error: ld returned 1 exit status<br></d=
iv><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>
--000000000000a52a2505d335219d--
--===============7792554527040894627==
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
--===============7792554527040894627==--