There are a few things that Octave Forge packages need to get from Octave itself that mkoctfile doesn't currently allow a way to query. This has come up before, I think with Octave 4.0, but hasn't been addressed yet. I think it would be great to allow all Octave Forge packages to cross compile without the need to call Octave at build time, just rely on the cross-mkoctfile executable. Should we start a separate tracker for that? Start a thread on the maintainers list? Can I start by crawling through all the Forge packages and finding out what those things are and why they are needed?

Thanks for the quick fix!

Sure, if you can easily fix it so that it works.

Longer term, I would like to update and simplify the way these packages are configured and built.  Looking at gsl, it is really complicated by having scripts to generate the configure.ac file.  I don't see why that should be necessary.  Any repetitive things that need to be done could be handled by m4 macros or just in the configure script itself since both of those are programming languages.

I understand that changes in Octave's internals causes some trouble.  Maybe there are ways we could make it easier for packages to determine what Octave features are available.  OTOH, building a current package for a 10-year old version of Octave makes little sense to me.  So I don't believe we need to make packages compatible with more than a few previous major releases of Octave.

Yes, definitely.

Meanwhile, what's the best way forward to get these packages to build for the upcoming 4.4.1 release?

Cross compiling the mxe-octave of-gsl package for Windows fails with the following error message:

checking ov-scalar.h usability... no
checking ov-scalar.h presence... no
checking for ov-scalar.h... no
configure: error: ov-scalar.h header not found
-verbose
gsl-2.1.1.tar.gz
mkoctfile= /scratch/build/mxe-octave-w32/usr/bin/i686-w64-mingw32-mkoctfile --verbose
arch= i686-w64-mingw32
apiversion= api-v52+
prefix= /scratch/build/mxe-octave-w32/usr/i686-w64-mingw32
files= ['gsl-2.1.1.tar.gz']
verbose= True
running ./configure --host='i686-w64-mingw32' --build='x86_64-pc-linux-gnu'
cleaning up

The configure test is written as

dnl *** Test some Octave features ***
dnl *********************************

dnl Find Octave's include directory
AC_MSG_CHECKING([for Octave's include directory])
octave_include_dir=`$OCTAVE -qf --eval "              \
  if exist ('__octave_config_info__')                 \
    disp  (__octave_config_info__ ('octincludedir'))  \
  else                                                \
    disp  (octave_config_info ('octincludedir'))      \
  end"`
AC_MSG_RESULT([${octave_include_dir}])

dnl Save initial state
save_CPPFLAGS=${CPPFLAG}
AC_LANG_PUSH([C++])

dnl Add octave include dir to CPPFLAGS
CPPFLAGS="-I${octave_include_dir} ${CPPFLAGS}"

dnl Detect ov-scalar.h
AC_CHECK_HEADER([ov-scalar.h],,[AC_MSG_ERROR([ov-scalar.h header not found])])

We can't run the cross-built Octave in this situation.  If some version of Octave that we can run is installed, then it will give information about the build system, not the host system that we are interested in.

Instead, we could use $MKOCTFILE here to compile C and C++ files.  It is already set up to look in the Octave include directory, and the mxe-octve build system sets the MKOCTFILE variable to the name of the cross version of mkoctfile (in my case, "i686-w64-mingw32-mkoctfile".  If you do need info about the host system, you can also get it from running this version of mkoctfile.