Re: mostly successful windows build

--===============4773488950516328899==
Content-Type: multipart/alternative; boundary="0000000000008d74ff05d32e692f"

--0000000000008d74ff05d32e692f
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr">The error building excel plugin is a complete mystery to m=
e.=C2=A0 =C2=A0I am getting :<div><br></div><div>=C2=A0 CCLD =C2=A0 =C2=A0 =
<a href=3D"http://excel.la">excel.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&#39;:<br>C:\msys64\home\travi\g=
numeric\plugins\excel/ms-excel-read.c:2312: undefined reference to `sheet_s=
tyle_apply_border&#39;<br>collect2.exe: error: ld returned 1 exit status<br=
>make[4]: *** [Makefile:617: <a href=3D"http://excel.la">excel.la</a>] Erro=
r 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&#39;t see any problem with how sheet_style_apply_border is defined and =
I don&#39;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 &lt;<a href=3D"mailto:[email protected]=
m">[email protected]</a>&gt; 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">I made an effort to build gnumer=
ic under MSYS2 MINGW on Windows 10.=C2=A0 There were only a few minor issue=
s to getting a mostly working=C2=A0application.=C2=A0 I thought I would sen=
d a report here in case others want to follow.<div><br></div><div>I am usin=
g the UCRT64 environment.=C2=A0 That links with the more standards-complian=
t 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 except goffice and gnumeric which I built from source (=
git latest as of a few days ago).</div><div><br></div><div>An incomplete li=
st of packages I installed:</div><div>=C2=A0 pacman -S mingw-w64-ucrt-x86_6=
4-gtk-doc<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-gtk3<br>=C2=A0 pacman -=
S mingw-w64-ucrt-x86_64-libgsf<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-li=
bxml2<br>=C2=A0 pacman -S mingw-w64-ucrt-x86_64-gettext<br>=C2=A0 pacman -S=
 mingw-w64-ucrt-x86_64-yelp-tools<br></div><div><br></div><div>The minor is=
sues:</div><div>For both goffice and gnumeric there are similar syntax erro=
rs in the configure file generated by autogen.sh.=C2=A0 I haven&#39;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 parenthesis=
=C2=A0and extra newline in a case statement around line=C2=A06448 and a spu=
rious 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 r=
eads=C2=A0</div><div><br></div><div>=C2=A0 case $as_dir in #(((<br>=C2=A0 =
=C2=A0 &#39;&#39;<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&#39;t know if the parenthesis=C2=A0somehow gets teleported hundreds =
of lines later?</div><div><br></div><div>There is a minor 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/reference/Makefile.am<br>ind=
ex 3278839c..1afb26c1 100644<br>--- a/docs/reference/Makefile.am<br>+++ b/d=
ocs/reference/Makefile.am<br>@@ -48,6 +48,10 @@ GTKDOC_LIBS =3D $(top_build=
dir)/goffice/libgoffice-@[email protected] $(GOFFICE_<br><br>=C2=A0includ=
e $(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" 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 list some months ago =
about windows missing the isnanl=C2=A0function.=C2=A0 Morten mentioned it w=
as possible to just disable long double support by a build flag.=C2=A0 I su=
pplied my own implementation in the 3 files affected (goffice/math/go-R.c, =
goffice/math/go-math.c, goffice/math/go-quad.c) as=C2=A0</div><div><br></di=
v><div>=C2=A0 int isnanl(long double x) { return (!((x&gt;=3D0)||(x&lt;=3D0=
))); }</div><div><br></div><div>This is a bodge; the right solution I think=
 is that autotools can supply this function on 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 problem that configure notes about=
 missing rand functionality that is probably related to random numbers not =
working in the gnumeric build (see below).</div><div><br></div><div>After m=
ake and make install of goffice, I moved on to gnumeric.=C2=A0 There is the=
 same problem of the teleporting parenthesis in the configure file.=C2=A0 T=
hen there is an issue again mentioned on this list months ago where some wo=
rkaround for windows command line localization is broken and doesn&#39;t co=
mpile (or glib is broken I guess?).=C2=A0 Anyway 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-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 n=
ot do it again.<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* <a href=3D"http://bu=
gzilla.gnome.org/show_bug.cgi?id=3D361321" target=3D"_blank">http://bugzill=
a.gnome.org/show_bug.cgi?id=3D361321</a> */<br>- =C2=A0 =C2=A0 =C2=A0 g_opt=
ion_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_conte=
xt_add_group (ocontext, gtk_get_option_group (TRUE));<br></div><div><br></d=
iv><div>The only other bit I had to add was in the CFLAGS of the gnumeric m=
akefile -fcommon.=C2=A0 This is I think needed on other platforms with late=
st gcc as well, as gcc changed the default from -fno-common to -fcommon.</d=
iv><div><br></div><div>I get a gnumeric.exe that runs and looks very=C2=A0n=
ice.=C2=A0 I only tried simple things so far.=C2=A0 Running sstest.exe ther=
e are failures from test_random:</div><div><br></div><div>SUMMARY: FAIL for=
 RAND, RANDUNIFORM, RANDBETA, RANDCAUCHY, RANDCHISQ, RANDEXP, RANDFDIST, RA=
NDGAMMA, RANDLOG, RANDLOGNORM, RANDNORM, RANDSNORM, RANDTDIST, RANDWEIBULL,=
 RANDRAYLEIGH, RANDBERNOULLI, RANDBETWEEN, RANDBINOM, RANDDISCRETE, RANDGEO=
M, RANDHYPERG, RANDNEGBINOM, RANDPOISSON<br></div><div><br></div><div>It lo=
oks 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 executa=
ble which I didn&#39;t chase yet; I was excited to see gnumeric.exe come ou=
t :-).=C2=A0=C2=A0</div><div><br></div><div>This failure I haven&#39;t look=
ed 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 fu=
nction `excel_set_xf&#39;:<br>C:\msys64\home\travi\gnumeric\plugins\excel/m=
s-excel-read.c:2312: undefined reference to `sheet_style_apply_border&#39;<=
br>collect2.exe: error: ld returned 1 exit status<br></div><div><br></div><=
div>--Travis</div><div><br></div><div><br></div><div><br></div><div><br></d=
iv><div><br></div><div><br></div></div>
</blockquote></div>

--0000000000008d74ff05d32e692f--

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

--===============4773488950516328899==--