mathgl fails to satisfy its cross Build-Depends, because its dependency
on liboctave-dev is not satisfiable. liboctave-dev depends on toolchain
packages such as gcc, g++ or gfortran. This is very unusual. Most
commonly, C-libraries can depend on other C-libraries, but users are
expected to install their desired toolchain themselves. These
dependencies need toolchain dependency translation in order to work for
cross building. Unfortunately, toolchain dependency translation is not
yet implemented. Thus I think removing these dependencies is required. I
looked into debian/changelog for why they were added and couldn't find a
reason. Can we simply drop them?

Helmut

* Helmut Grohne <helmut@subdivi.de> [2019-07-28 22:32]:

I think that the reason is historical.  At least since version 2.1.64-3,
released 14 years ago, g++ and g77 | fort77 appear as dependencies of
octave2.1-headers. [1] The package octave2.1-headers is the predecessor
of liboctave-dev.

This dependency may have been introduced before this version, but version
control started at that point and there is no way to figure out now when
and why those dependencies were introduced.

I would say that it is okay to drop the dependencies on gcc, g++ and
gfortran, as you suggest, but I will let the other members of the
Debian Octave comment on this issue.

Rafaek

[1] https://salsa.debian.org/pkg-octave-team/octave/blob/be338881462f4e5b45483eb2d18b7fab059c057e/debian/control

Hi Helmut, Rafael,

I think the reason for the dependency is because liboctave-dev also
ships /usr/bin/mkoctfile, which is a wrapper for gcc|g++|gfortran to
compile Octave extensions. Users install liboctave-dev and expect to be
able to run mkoctfile to build native .mex or .oct files.

One solution may be to introduce a new package, say 'octave-dev-tools',
that would ship /usr/bin/mkoctfile and Depends: liboctave-dev. This
might allow the possibility of cross-building with liboctave-dev. This
would have a large impact on documentation, FAQs, and other accumulated
knowledge that tells users to install 'liboctave-dev' to be able to
compile and install packages.

I want to also mention that liboctave-dev includes a small number of
header files in /usr/include that are generated and include
arch-specific contents:

    usr/include/octave-5.1.0/octave/mxarray.h
    usr/include/octave-5.1.0/octave/octave-config.h
    usr/include/octave-5.1.0/octave/version.h

Does this require any specific handling with respect to multi-arch and
cross-building?

Hi Rafael and Mike,

Thank you for this quick and insightful answer. This is a very good
reason.

Unfortunately, this would also be insufficient for a number of uses, so
we should consider whether this is worth the effort. Quite possibly,
we'll conclude: wontfix.

We have a number of compiler wrappers (i.e. something that calls a
compiler somehow) in Debian and each of them is problematic to cross
building. Let me recap a few of them to give you an idea of the issues:

 * mpicc is a compiler wrapper for adding mpi flags. We've generally
   concluded that this is fully incompatible with cross building. We're
   trying to obsolete mpicc now and use pkg-config instead.
 * valac can act as a compiler wrapper and we don't have a solution at
   present (#889925). This one may be most similar to mkoctfile.
 * diet is a compiler wrapper for the dietlibc and I have no clue how to
   fix it at all.

In general, compilers have architecture-specific behaviour.  For cross
building you need to tell them which architecture you want binaries for.
In Debian, we do that by prefixing them. Rather than "gcc" you say
"${DEB_HOST_GNU_TYPE}-gcc". Any wrappers inherit this need. So we'd have
to have "${DEB_HOST_GNU_TYPE}-mkoctfile" and convert users to use these
prefixed names.

Any transition from the status quo to supporting cross builds will have
user visibile consequences. For this reason, we should not rush this at
all.
Multi-Arch: same. This is a problem if you want to build for multiple
architectures simultaneously. When building in chroots, this is less of
a problem as you can simply create multiple chroots with conflicting
packages. The usual solution is to move them to
/usr/include/${DEB_HOST_MULTIARCH}. Without working on mkoctfile, there
is no benefit in doing so however as the presence of mkoctfile also
prevents us from using Multi-Arch: same.

I had hoped that this is low hanging fruit. Quite obviously, it is not.
Are you interested in looking into this complex matter anyhow? If not,
we should likely close this bug as "not fixable with reasonable effort".

I've very little clue about ocatve, but I can assist with all the cross
building and multiarch matters. It's the combined knowledge of us that
can make a dent on the issue, not an individual's.

Helmut

* Helmut Grohne <helmut@subdivi.de> [2019-07-29 08:15]:

I would love to contribute, but my free time budget is near to zero right
now.  Furthermore, I have almost no knowledge on multiarch issues.

I am hereby tagging this bug report “wontfix.” Let us keep it open for
now.

Rafael