Please ignore the last part of my previous post. With a current tip without local changes, everything is working as expected.

That means I still see bug #54165 but the GUI opens without error.

Did you run "./bootstrap" before "make dist-gzip"?

Not quite the same thing, but I'm also not able to build MXE octave.  I used 'make dist-gzip' to create a gzip version of the latest development source code.  I copied that in to the pkg/ directory of mxe octave, and then commented out the PKG_URL line in src/default-octave.mk so that the gzip file will be used.

When I try to build I get an error about mkostemps.

liboctave/wrappers/.libs/libwrappers.a(liboctave_wrappers_libwrappers_la-mkostemps-wrapper.o): In function `octave_mkostemps_wrapper':
/home/rik/wip/Projects_Mine/mxe-octave/tmp-default-octave/octave-5.0.0/liboctave/wrappers/mkostemps-wrapper.c:39: undefined reference to `mkostemps'
collect2: error: ld returned 1 exit status

Any ideas what is missing?

OK, I hope this is the last fix needed for this bug report:

http://hg.savannah.gnu.org/hgweb/octave/rev/b61f3500651f

Sorry for all the trouble.

The cross-build stopped for of-control at the following command:

/home/osboxes/Documents/Repositories/Octave/mxe-octave-6/usr/bin/x86_64-w64-mingw32-mkoctfile --verbose -c *.f
mkoctfile: may not use -c and -o with multiple source files
Makefile:27: recipe for target 'slicotlibrary.a' failed
make[2]: *** [slicotlibrary.a] Error 1

If I am reading the commit message to http://hg.savannah.gnu.org/hgweb/octave/rev/f35bd5cddedd correctly, it should still be possible to use multiple source files if only "-c" (not also "-o") is specified.
Is that a bug in mkoctfile or in how of-control is using it?

No, we should not be using gnulib when CROSS is defined.  When CROSS is defined, we are building an executable to run on Linux that builds .oct files that are intended to run on Windows.  And mxe-octave has only configured and built a copy of gnulib for Windows, not Linux.

I fixed it this way instead:

http://hg.savannah.gnu.org/hgweb/octave/rev/ace13ff63b90

There is no distinction between text and binary files on Linux systems, so O_BINARY shouldn't be needed in the flags argument of mkostemps anyway.

If at some point we decide that we do need the portability fixes that gnulib provides when we are building mkoctfile with CROSS defined, then we'll have to fix the mxe-octave and Octave build systems so that when cross compiling, we cross-compile gnulib AND we also build a native version that can be used when building the cross-compiler version of the tools like mkoctfile (i.e., the one that runs on Linux and creates Windows .oct files).  That seems like a lot of unnecessary work at this point so I only want to do it if it is really needed.

Thanks for the explanation.

I am still seeing the same error with http://hg.savannah.gnu.org/hgweb/octave/rev/ec2492a2af6a

Maybe a different header is picked? Should there be a "-Ilibgnu" somewhere in the makefile rule?

After that change, cross-building for Windows with MXE Octave fails with the following error:

src/x86_64-w64-mingw32-mkoctfile.cc: In function ‘int octave_mkostemps_wrapper(char*, int)’:
src/x86_64-w64-mingw32-mkoctfile.cc:76:38: error: ‘O_BINARY’ was not declared in this scope
   return mkostemps (tmpl, suffixlen, O_BINARY);
                                      ^~~~~~~~
src/x86_64-w64-mingw32-mkoctfile.cc:76:38: note: suggested alternative: ‘L_INCR’
   return mkostemps (tmpl, suffixlen, O_BINARY);
                                      ^~~~~~~~
                                      L_INCR
Makefile:27762: recipe for target 'src/x86_64-w64-mingw32-mkoctfile' failed

Gnulib's fcntl.h defines O_BINARY for that platform. [1]
Do we want to include gnulib headers when building mkoctfile?  I don't know the background for not using our wrappers when cross-compiling.

[1]: https://www.gnu.org/software/gnulib/manual/html_node/fcntl_002eh.html

Wow.  Pulled on a thread and the whole sweater came undone.

It all seems to work though.  I had to install the generated version of Octave in order for the correct mkoctfile to be picked up.  After that testing worked fine.

Shouldn't "mkostemps" be added as a module in bootstrap.conf if we are using it from gnulib?  See https://www.gnu.org/software/gnulib/manual/html_node/mkostemps.html#mkostemps

When running the test suite multiple .o object files are created at the top-level directory during testing of the MEX interface.

The root cause is that 'mkoctfile --mex' generates not only the output .mex file, but also the intermediate .o file.

This is not how the analogous gcc command works. 'gcc hello.c' produces only 'a.out'.  The intermediates are removed/suppressed.  If you want to only perform compilation, but prevent the linker from running, you need to specifically give the option '-c'.

Octave should change its interface to do something similar and only preserve the object files when specifically requested.