On Mon, 01 May 2023 at 16:21:55 +0200, Matthias Klose wrote: > On 01.05.23 14:53, Simon McVittie wrote: > > This seems inconsistent: I would have expected that binutils-TUPLE would > > either always provide TUPLE-gold, or never provide TUPLE-gold. > > this is an oversight, will fix this in experimental.
Thanks! This part (gold) was what prompted me to open this bug. > > Similarly, binutils-x86-64-linux-gnu:amd64 provides TUPLE-gp-archive (and > > other gp- tools) and TUPLE-gprofng, but binutils-x86-64-linux-gnu:ppc64el > > doesn't provide those. > > the profiling parts are not included in the cross packages by intent. Is > there a use case where these are necessary? Shouldn't you be able to use > the native packages? I didn't know and didn't check what these tools are for, I just noticed while reporting this bug that they were present in native binutils-x86-64-linux-gnu but not in cross binutils-x86-64-linux-gnu, which seemed odd. Cross binutils do have TUPLE-gprof, but not TUPLE-gprofng or the TUPLE-gp- family. I can see that profiling a non-native executable is likely to lead to misleading results, because even if you can run it via qemu or something, the times are not going to reflect how fast or slow a real CPU of the same architecture would be; so from that point of view, omitting these makes sense. 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. smcv