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