Does this make sense when Go binaries are built with standard Go macros? @jcajka, could you verify?

I don't think outright disabling the checks makes sense(as they from quick look on the python check script make sense, even for Go, to me). IIRC we use in fedora pie build mode of Go. That will generate pie binaries. In the linked issue example it should AFAIK in default mode produce static binaries(in C sense). I don't remember from top of my head how "static" pie (elf) C binaries looks like but I would assume that Go ones will look the same. I will double check.

Does this make sense when Go binaries are built with standard Go macros? @jcajka, could you verify?

@Conan-Kudo BTW do you remember to what and where are the "gobuildflags" set nowadays?

Other issue, uh... more factor, might be that the CGO got disabled for the build of the binaries, IMO the rpmlint can't realistically cater for such manual fine tuning, on other hand should probably handle it more gracefully.

@Conan-Kudo What do you think about this pull request?

I'm not sure it makes sense to incorporate this into rpmlint, given @jcajka's feedback. Actually, I wonder if we might be doing something wrong in openSUSE that we're not getting PIE and debuginfo+build-ids enabled on Go builds there...

Ok, so taking the provided example from the bug and my analysis:
#598 (comment)

We report the following:

$ ./lint.py /tmp/example-1.0-1.utm.x86_64.rpm
...
example.x86_64: E: shared-library-without-dependency-information /usr/bin/example1
example.x86_64: E: shared-library-without-dependency-information /usr/bin/example2
...

So either the provided Go shared library is self-contained (does not link to any shared library) and it's fine or the error message is correct and we can close the reported issue?

What should I choose @jcajka ?