site
contact
newsFile utility confuses executable and shared library
All Linux users have had this problem for the last couple of
years. It used to be, that the 'file' utility clearly distinguished
between a binary executable and a shared library. For example,
'btcflash' is a binary executable:
# file /usr/bin/btcflash
/usr/bin/btcflash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6793c33577aa89c724c56dfa244bf794b3160426, stripped
...the key text is "ELF" and "executable".
Also, shared libraries were clearly different, for example 'libcap.so.2.32':
# file /lib/libcap.so.2.32
/lib/libcap.so.2.32: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7ad8598f3949378da2784f77689ab6e943c193af, stripped
Unfortunately, a couple of years ago we started to get binary
executables showing as shared library type, that is, as "ELF 64-bit LSB
shared object".
File managers such as ROX-Filer, are now showing binary executables with the same icon as shared-library files.
The reason for this problem is that gcc changed to default to create
position-independent-executables (pie), which the 'file' utility was
unable to distinguish from shared library files.
However, with 'file' version 5.36, there was a fix. Now, we get this, the example is 'ed':
# file /bin/ed
/bin/ed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, BuildID[sha1]=72051644a78b1045aca6080733e6f7fe1b2bfaff, for GNU/Linux 3.2.0, stripped
....see the string "pie executable".
Great. Well, no. A developer made a commit before the release of
'file' 5.38 that broke that new behaviour, and went back to executable
being identified as "shared object".
That must have caused a clamour, as version 5.39 has restored "pie executable". 5.39 was released June 2020.
We are not yet "out of the woods", as ROX-Filer shows binary
executables as mime type "application/x-sharedlib". ROX is using the
'shared-mime-info' package to determine mime type. I have not
investigated that yet, next on the to-do list.
So far, will be bumping the Dunfell build of EasyOS to using 'file' 5.39.
EDIT:
I looked at the latest commits for the 'shared-mime-info' package, and found this, committed to master 3 month ago:
I applied the patch to version 1.15 and recompiled in OE, then tested in EasyOS.
Hmmm, yes, all binary executables now show as
"application/x-executable" and ROX-Filer displays the appropriate icon,
and of course they can now be clicked-on to execute.
However, now most of the shared library files show as "application/x-executable" also.
The patch is, I think, what Americans would
call "half assed". The developer really should have studied how it was
fixed in the 'file' package and implemented a more "proper" fix.
Anyway, will leave that patch in, it is probably an improvement.
EDIT2:
I have implemented a fix so that all shared library files now show as
"application/x-sharedlib". This is a hack, but works. I could, or rather
should, have done it in the source code, but I have added an extra file
to perform a correction. Here is the file,
/usr/share/mime/packages/sharedlib.xml:
<?xml version="1.0" encoding="utf-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<!-- BK: this is a hack to force shared libs to be recognised correctly -->
<!-- ref: https://bkhome.org/news/202010/file-utility-confuses-executable-and-shared-library.html -->
<mime-type type="application/x-sharedlib">
<comment>shared library</comment>
<glob pattern="*.so"/>
<glob pattern="*.so.*"/>
</mime-type>
</mime-info>
So any file with ".so." anywhere in it's name is going to show as a shared library file. Reckon I can live with that.
It is just a matter of running "update-mime-database /usr/share/mime" to apply the change.
Tags: easy