On Wed, Sep 13, 2017 at 10:01 PM, Helmut Grohne <hel...@subdivi.de> wrote:
> I'm not sure why you felt the need to append a version, but my attached
> patch supports your need by adding a --gccsuffix option to debcrossgen
> while defaulting to an unversioned gcc as is expected by most Debian
> packages. I also made it honour the environment variables CC and CXX by
When compiling with Meson, CC and CXX must point to the native
compilers, not to cross compilers. If the crossgen tool uses CC that
means that debuild needs to first set it to the cross compiler, run
crossgen and then set it to the native compiler. Is this a natural way
of doing it for debuild or does it cause complications?
> I took some time looking into the cpu and cpu_family variables and am a
> little confused what to put there. Experimentation with native meson
> shows the following strange results:
Yes, we do indeed to some canonicalization here. In Meson terms the
"cpu_family" means the CPU type that is native to the given platform,
_not_ the CPU type of the kernel currently running.
> mips mips64 mips64
> mipsel mips64 mips64
These should be plain mips (assuming that this is mips32 userland
running on top of a 64 bit kernel).
> powerpc ppc64 ppc64
We do the magic normalization here:
This script should probably do the same thing as that one. With a bit
of refactoring it could even import that function since it ships in
the same (private) directory as the code itself.
> I'm not sure why all the tools use absolute paths, but I implemented
> that path lookup generically now. If it turns out to be unnecessary, you
> can remove it.
Some toolchains do not have different executable names for the
compiler and cross compiler. Thus absolute paths are needed to ensure
they do not get mixed up by accident.