Martin Liška

Yes, please compile it on your own. I can attach an example output, however, the format change is pretty cosmetic.

Sure, here it is: [gcov-17.json.txt](https://github.com/gcovr/gcovr/files/11212533/gcov-17.json.txt)

> > Sure, here it is: [gcov-17.json.txt](https://github.com/gcovr/gcovr/files/11212533/gcov-17.json.txt) > > In the gcov human readable output there is also a callno, e.g.: > > ``` > call 17 returned 9 >...

I've got your point, you're calling for consistency. However, if you consider a gcov output: ``` 1: 41-block 0 call 0 returned 100% branch 1 taken 100% (fallthrough) branch 2...

> > I see it as rather confusing for normal output as the indices are shared in between calls and branches within a basic-block. That's not super-intuitive. > > But...

> I expect that the IDs are added to the generated file the same way as it is in the human readable file. As explained, I don't like the way...

> I don't know if this library comes with binutils-dev or if it needs to be installed separately. I haven't reproduced yet. Hey. The library is provided by the very...

One more note about what happens with `-lbfd`. In the case of openSUSE, we intentionally don't ship shared library `libbfd.so`, but only a static version that we link against. Unfortunately,...

I'm saying it happens with a **static** libbfd library (that's what we provide in openSUSE).

And the situation gets even more complicated when it comes to the latest release. `libbfd` newly supports `zstd` compression and thus one ends with: ``` [ 71s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/12/../../../../lib64/libbfd.a(compress.o): in...