i'm pretty sure rust is producing ELFs.  it seems extremely unlikely it's producing any other executable format since the kernel only supports ELFs, and we aren't allowing any new interpreters onto the system.

which means we still want ELF checks, and disabling the binchecks in the eclass is incorrect.

It's correct to still have binchecks, but it appears this failing check is looking for a section labeled '.GCC.command.line' which, by my naive interpretation, is something only gcc-compatible compilers would include. It wouldn't even make sense for rustc to output that section as its command line options are totally different.

which is mostly what issue 642230 is about

the gold check does not rely on command line flag tracking

I think this issue is totally independent of the one you mentioned. Fundamentally, it makes no sense to check certain GCC flags were used to build a binary that GCC had no part in producing.
It's true that the binary was not built with gold because it was linked with  x86_64-pc-linux-gnu-gcc (which seems like a contradiction of my previous sentence but this gcc invocation is purely for linking purposes), which after some interrogation with -print-prog-name=ld, said it uses the bfd version of ld.

that issue covers builds by clang too which are impacted.  i don't think special casing rust is worth the effort.

So we're in agreement that disabling binchecks is the correct choice for non-gcc packages that build binaries?

of course not.  the *one* bad check you highlighted is just a single check.  turning off all binchecks disables a lot more checks that do make sense.

you should just ignore it and wait for issue 642230 to be resolved.

I'll just merge it with that then.