Control: tags -1 - patch
Control: severity -1 wishlist
Hi Rafael and Mike,
On Sun, Jul 28, 2019 at 03:48:37PM -0700, Mike Miller wrote:
> 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.
Thank you for this quick and insightful answer. This is a very good
reason.
> 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.
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.
> 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?
Possibly. These headers mean that liboctave-dev cannot be marked
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
