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 <traviswfis...@gmail.com>
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-@GOFFICE_API_VER@.la $(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
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
