Re: mostly successful windows build



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








[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]