[debian-mysql] Bug#920365: mariadb_config: improve cross compilation support

[Helmut Grohne]

Hi Sergei,

Please be aware that the Debian BTS does not automatically Cc
submitters. I found your reply by chance.

On Sat, Jan 26, 2019 at 07:37:14PM +0100, Sergei Golubchik wrote:
> I would say that when cross-compiling mariadb_config should be built for
> the host architecture.

That is the status quo, but I guess you're confusing terms here. Please
refer to man dpkg-architecture for what build/host/target mean.

> You'll get "Exec format error" if you run'll run it on the target
> architecture, but that should not be a problem, as you will not need to
> run mariadb_config on the target architecture. Because mariadb_config is
> a helper tool to build applications, and you build on the host
> architecture for the target architecture. You don't need mariadb_config
> to use libmariadb.

I'm going to assume that whenever you write "target" you actually mean
"host" and whenever you write "host" you actually mean "build".
Otherwise this paragraph doesn't make any sense at all.

I kinda agree that you'd want to have mariadb_config for the build
architecture, but that's not what is currently happening nor is it
reasonably achievable. Currently, mariadb_config is shipped with
libmariadb-dev and you need libmariadb-dev for the host architecture
(for linking it). Thus mariadb_config is a host architecture executable
and cannot be run.

Now how would one change that? We'd have to add a new package (say
libmariadb-dev-bin) which contains mariadb_config. Now you'd somehow
install libmariadb-dev for the host architecture (for linking) and
libmariadb-dev-bin for the build architecture (for running
mariadb_config). Unfortunately, the behaviour of mariadb_config is
architecture-dependent as it emits different paths and flags for
different architectures. So you actually need one mariadb_config for
every *pair* of architectures: One is the architecture you want to run
it on and the other is the architecture you want it to tell you things
about. So libmariadb-dev-bin would much rather be
libmariadb-dev-bin-${architecture}. And the number of mariadb_config you
have to build explodes. With 10 release architectures, you build 100
mariadb_config executables. Adding 10 ports architectures and you have
no less than 400 mariadb_config executables. This is going to be messy.
Very messy.

> Do you mean that you've built libmariadb on one (host) architecture,
> copied to another (target) architecture. And then you want to build
> various applications (that use libmariadb) directly on the target
> architecture? That's confusing, if your target architecture has a
> working development environment, why not to build libmariadb there too?

Presently, I'm going to assume that one somehow built libmariadb and
copied it over to another system, yes. However the intention is to
eventually cross build libmariadb itself. The typical use case is
building a customized Debian derivative for embedded systems: You can
use some packages as is, but you need to modify others. Given that your
embedded system is slow, you cross build on a fast X86 machine.

> I'm afraid, I don't understand your use case.

I'm working at all ends concurrently. I don't have to wait for
libmariadb to be cross buildable before I can start working on building
libmariadb's reverse dependencies. The goal is to cross build OS images
from Debian (similar to Yocto/Buildroot/PtxDist). Let's see whether we
get there. This generator is an intermediate step to make progress on
reverse dependencies.

Helmut