strace_analysis needs to handle known gcc compiler or devkit version/location

[andrew-m-leonard]

strace_analysis.sh currently reports:

14:33:34  Packages where version cannot be identified:
14:33:34  /usr/local/gcc11/include/c++/11.2.0/aarch64-unknown-linux-gnu/bits/atomic_word.h
....

We should have a way of telling the script that a known gcc compiler or devkit is in location /usr/local/gcc11 for example..

[sxa]

We should have a way of telling the script that a known gcc compiler or devkit is in location /usr/local/gcc11 for example..

Is the purpose of those to exclude those entries? To my mind those messages are correct (i.e. they're not associated with an rpm) so what are you proposing we do with them.

[andrew-m-leonard]

We should have a way of telling the script that a known gcc compiler or devkit is in location /usr/local/gcc11 for example..

Is the purpose of those to exclude those entries? To my mind those messages are correct (i.e. they're not associated with an rpm) so what are you proposing we do with them.

no, the purpose to aid it in identifying what the gcc/devkit folder is and add correctly to the SBOM.
eg.maybe add some option like:
-identified-package "/usr/local/gcc11" "gcc Adoptium/sxa v11.2.0 https://ci.adoptium.net/userContent/gcc/gcc112.x86_64.tar.xz"
Thus any headers etc found under /usr/local/gcc11 would be identified as such...

sbin/build.sh knows what's in /usr/local/gcc11 so it can tell the analysis script, rather than just ignoring it as is currently the case

[sxa]

OK gotcha ... Initial gut feel is that I'd be tempted to pull the version string, maybe record the SHA of the gcc executable or something (thinking off the top of my head). If be nervous about having an explicit mapping back to the tarball URL when it can't be proved. (Noting that none of the rpms can be proved to be accurate, other than by being able to do a reproduce comparison)

[andrew-m-leonard]

OK gotcha ... Initial gut feel is that I'd be tempted to pull the version string, maybe record the SHA of the gcc executable or something (thinking off the top of my head). If be nervous about having an explicit mapping back to the tarball URL when it can't be proved. (Noting that none of the rpms can be proved to be accurate, other than by being able to do a reproduce comparison)

So yeah, the /usr/local/gcc11/bin/gcc will already been pulled out correctly by the script and gcc -version of it.., it's just when it analsyses files like:
/usr/local/gcc11/include/someheader.h
it needs some intelligent logic to tie this to /usr/local/gcc11/bin/gcc ...

[andrew-m-leonard]

OK gotcha ... Initial gut feel is that I'd be tempted to pull the version string, maybe record the SHA of the gcc executable or something (thinking off the top of my head). If be nervous about having an explicit mapping back to the tarball URL when it can't be proved. (Noting that none of the rpms can be proved to be accurate, other than by being able to do a reproduce comparison)

So yeah, the /usr/local/gcc11/bin/gcc will already been pulled out correctly by the script and gcc -version of it.., it's just when it analsyses files like: /usr/local/gcc11/include/someheader.h it needs some intelligent logic to tie this to /usr/local/gcc11/bin/gcc ...
So an input script param that maps /usr/local/gcc11/* to whatever it determines /usr/local/gcc11/bin/gcc to be...?

[andrew-m-leonard]

This has already been fixed by https://github.com/adoptium/temurin-build/pull/3867/files