On 01.05.23 21:12, Simon McVittie wrote:
For related CPU families like x86_64/i386 and arm64/armhf/armel,
am I correct to assume that there's enough multilib support for
binutils-x86-64-linux-gnu:amd64's gprofng to be able to profile an
i686-linux-gnu executable, and so on? But that would mean that a build
system for build=amd64, host=i386 needs to know that it's OK that
i686-linux-gnu-gprofng won't exist and it should fall back to plain
gprofng (or equivalently, x86_64-linux-gnu-gprofng).
My concern about these was that having them in native binutils but not in
cross-binutils means the command-line "API" of binutils-x86-64-linux-gnu
is different depending on what architecture's version you have. But if
those differences are considered harmless (either because build systems
are expected to fall back from i686-linux-gnu-gprofng to gprofng like
Autotools would, or because using a tuple-prefixed gprofng doesn't actually
make sense and users should stick to the unprefixed one) then that's fine.
I haven't looked into this. If these are architecture dependent, you would have
to package libgprofng.so with a different soname as well.
