mostly successful windows build

--===============8849855310899731592==
Content-Type: multipart/alternative; boundary="00000000000021a0c505d31707a6"

--00000000000021a0c505d31707a6
Content-Type: text/plain; charset="UTF-8"

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

--00000000000021a0c505d31707a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I made an effort to build gnumeric under MSYS2 MINGW on Wi=
ndows 10.=C2=A0 There were only a few minor issues to getting a mostly work=
ing=C2=A0application.=C2=A0 I thought I would send a report here in case ot=
hers want to follow.<div><br></div><div>I am using the UCRT64 environment.=
=C2=A0 That links with the more standards-compliant UCRT runtime which may =
be an easier target than the older MSVCRT runtime.</div><div><br></div><div=
>I found MSYS2 packaged builds were available for everything required excep=
t goffice and gnumeric which I built from source (git latest as of a few da=
ys ago).</div><div><br></div><div>An incomplete list of packages I installe=
d:</div><div>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-gtk-doc<br>=C2=A0 pacma=
n -S mingw-w64-ucrt-x86_64-gtk3<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-l=
ibgsf<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-libxml2<br>=C2=A0 pacman -S=
 mingw-w64-ucrt-x86_64-gettext<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-ye=
lp-tools<br></div><div><br></div><div>The minor issues:</div><div>For both =
goffice and gnumeric there are similar syntax errors in the configure file =
generated by autogen.sh.=C2=A0 I haven&#39;t tried to understand the genera=
tion process; I fixed the configure file by hand.</div><div><br></div><div>=
For goffice there is a missing right parenthesis=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 should read</div><div><br></div><=
div>=C2=A0 case $as_dir in #(((<br>=C2=A0 =C2=A0 &#39;&#39;) 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 instead reads=C2=A0</div><div><br></=
div><div>=C2=A0 case $as_dir in #(((<br>=C2=A0 =C2=A0 &#39;&#39;<br>=C2=A0a=
s_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&#39;t know if the par=
enthesis=C2=A0somehow gets teleported hundreds of lines later?</div><div><b=
r></div><div>There is a minor problem with the goffice docs Makefile.am whi=
ch I fixed like this:</div><div><br></div><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 $(top_builddir)/goffice/libgoffice-@GOF=
[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://version.xml.in">version.xml.in</a><br><br>=C2=A0CLEAN=
FILES +=3D \<br></div><div><br></div><div>Then there is a problem mentioned=
 on this list some months ago about windows missing the isnanl=C2=A0functio=
n.=C2=A0 Morten mentioned it was possible to just disable long double suppo=
rt by a build flag.=C2=A0 I supplied my own implementation in the 3 files a=
ffected (goffice/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) { ret=
urn (!((x&gt;=3D0)||(x&lt;=3D0))); }</div><div><br></div><div>This is a bod=
ge; the right solution I think is that autotools can supply this function o=
n platforms it is missing.=C2=A0 Again I haven&#39;t learned autotools so I=
 just hacked it up by hand.</div><div><br></div><div>There is another probl=
em that configure notes about missing rand functionality that is probably r=
elated to random numbers not working in the gnumeric build (see below).</di=
v><div><br></div><div>After make and make install of goffice, I moved on to=
 gnumeric.=C2=A0 There is the same problem of the teleporting parenthesis i=
n the configure file.=C2=A0 Then there is an issue again mentioned on this =
list months ago where some workaround for windows command line localization=
 is broken and doesn&#39;t compile (or glib is broken I guess?).=C2=A0 Anyw=
ay remarking 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/src/main-application.c b/src/main-application.c<br>index ae8beaccd..=
865edd2c8 100644<br>--- a/src/main-application.c<br>+++ b/src/main-applicat=
ion.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 alr=
eady 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">htt=
p://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&#39;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&#39;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&#39;:<br>C:\msys64\home\travi\gnume=
ric\plugins\excel/ms-excel-read.c:2312: undefined reference to `sheet_style=
_apply_border&#39;<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>

--00000000000021a0c505d31707a6--

--===============8849855310899731592==
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

--===============8849855310899731592==--