[Buildroot] [PATCH] support/script/check-bin-arch: ignore /usr/share

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at free-electrons.com> writes:

 > Hello,
 > On Wed, 22 Mar 2017 09:24:56 +0100, Peter Korsgaard wrote:

 >> http://autobuild.buildroot.net/results/4e2/4e27559827f3ed75a12f13bd595998bf661b2aaf/build-end.log
 >> http://autobuild.buildroot.net/results/99e/99e4ed21116c721faf9f1d0349f312b357d333ee/build-end.log
 >> 
 >> I wonder if we shouldn't turn the tests around, E.G. instead of
 >> searching for elf files with a machine different from target, search for
 >> a files with machine == host.

 > Indeed, that's an option. We would need to have only the readelf
 > machine string for the most common build architectures (x86, x86-64),
 > and if Buildroot is used on a different architecture, we simply don't
 > do the check.

Exactly, or alternatively we run readelf on a host utility (E.G. HOSTCC)
to detect the machine string.


 >> This can naturally still fail if somebody adds a package (E.G. in
 >> br2-external) that installs a i386/x86-64 binary. Presumably this could
 >> happen if you want to include a PC application to inside the firmware
 >> (E.G. downloadable through the web interface and used for controlling
 >> the firmware or similar), but it doesn't get caught up in all these
 >> build issues about various other firmware files or slightly different
 >> machine strings (sparc / sparcv9, arcompat / arcv2)..

 > I must say I still like the fact that we detect sparc vs. sparcv9,
 > arcompat vs arcv2. I.e why do we have some binaries that have a
 > different machine number than most of the binaries being produced?

Sorry, I don't know enough details about Sparc and Arc. It indeed seems
strange.


 > But I agree it's of limited usefulness, so if you want me to change the
 > mechanism by inverting the logic, I can cook some patches.

Well, just like for all other BR features I want to ensure that the
complexity/gain relation is OK. If we need to add more and more
exceptions and perhaps more complicated/fuzzy matching to handle these
machine string variantions then I think it would make sense to invert
the test to simplify - But lets see how it goes.

-- 
Bye, Peter Korsgaard