Bash commands to fetch "info version" included in an executable?

[devEric69]

Hello,

I want to include a FileVersion and a ProductVersion in a Linux executable (from the "Options for project" window in the Lazarus IDE).

Under MS-Windows, I can see them when I make right-click and turbo-menu "File properties" of the binary. Under Linux (Debian or Ubuntu), only the ugo rights are displayed.

Is it possible to obtain these "info version" included in the executable, under the Linux OS itself?

[lucamar]

No, there's no "standard" way to read this info in Linux as in Windows.

Though you can easily write a "GetExeInfo" utility in (Free) Pascal by yourself.

[MarkMLl]

I don't think so, at least in a formatted form. There's stuff in https://github.com/MarkMLl/Contec_cms50dplus/blob/main/common/inifilesabout.pas for doing it under program control.

readelf -n will show you some relevant stuff e.g. the build version from the linker, otherwise there might be something in objdump.

TResourceStream in the FCL should give an indication of how the resources (which includes the version info) are stored in the binary (an ELF file). But as I've said I anticipate that formatting will be a problem, and there's somewhere around zero chance of getting the developers responsible for the various desktop environments and overall distreaux to "prettify" it... Hell, if they can't agree on something useful like FatELF of a code-signing mechanism...

MarkMLl

[devEric69]

I don't think so, at least in a formatted form. There's stuff in https://github.com/MarkMLl/Contec_cms50dplus/blob/main/common/inifilesabout.pas for doing it under program control.

Thanks for the info and sharing.

there's somewhere around zero chance of getting the developers responsible for the various desktop environments and overall distreaux to "prettify" it... Hell, if they can't agree on something useful like FatELF of a code-signing mechanism...

Indeed, I already tried with readelf: but it's still very "raw", an improved header dump like objdump does. So, I wanted to know if there was something else natively in the OS like other commands, or rather graphically, I had missed. I have my answer, now.


Otherwise, effectively it is quite simple to display this information from inside the compiled binary, in an "About" window or a command line "-h" option, from the versionresource.pp unit, ..., using TResourceStream.

Thank you for your answers.

[marcov]

readelf shows toolchain info, not user version info?

[dbannon]

The linux approach is more to pass the binary a -v or --version, from, obviously, the command line. Its somewhat universal that linux binaries respond with some sort of version information and exit when you do that.  Obviously, not useful from a GUI ....

Davo

[MarkMLl]

The linux approach is more to pass the binary a -v or --version, from, obviously, the command line. Its somewhat universal that linux binaries respond with some sort of version information and exit when you do that.  Obviously, not useful from a GUI ....

I believe the -- variant was a GNUism, and it's certainly been supported since I started using GNU utilities in the early 90s.

Lazarus handles --version and --help properly, fpc doesn't.

The readelf utility can report the build ID optionally inserted into a binary by the linker (i.e. the value depends on the project and isn't the linker version), but that's very little use in practice since it can be trivially spoofed. That's stored as a "Note".

I've not worked out what one should ask readelf to get even an unformatted dump of resources. I'm sure it makes sense to somebody...

MarkMLl

[marcov]

The linux approach is more to pass the binary a -v or --version, from, obviously, the command line. Its somewhat universal that linux binaries respond with some sort of version information and exit when you do that.  Obviously, not useful from a GUI ....

Or in any way to use programmatically since it requires program specific parsing. So this is a different thing IMHO.

(compare fpc -v  vs fpc -iV )

[lucamar]

(compare fpc -v  vs fpc -iv )

Fun fact:

Code: Pascal  [Select][+][-]

1. lucamar@Diana:~$ fpc -v
2. Free Pascal Compiler version 3.2.0 [2020/07/07] for x86_64
3. Copyright (c) 1993-2020 by Florian Klaempfl and others
4. Fatal: No source file name in command line
5. Fatal: Compilation aborted
6. Error: /usr/bin/ppcx64 returned an error exitcode
7. lucamar@Diana:~$ fpc -iv
8. Error: Illegal parameter: -iv
9. Error: /usr/bin/ppcx64 returned an error exitcode

It should be remembered that fpc options are case-sensitive; I think you meant fpc -iV:

Code: Pascal  [Select][+][-]

1. lucamar@Diana:~$ fpc -iV
2. 3.2.0

[marcov]

Yeah, typo, corrected.

But the point is that something visible somewhere, and something machine extractable are two different things. This also goes for FPC, which has a bunch of fpc -i options to that effect.

[dbannon]

Getting back to Eric's question, I assume he is writing both the pascal binary and the bash script (if any) that will be inquiring about the binary's version.  So, parsing output from -v should not be a problem.

(And away from Eric's question again, I too think its a strange omission that FPC does not respond, as it should IMHO, to -v and/or --version).

Davo

[lucamar]

(And away from Eric's question again, I too think its a strange omission that FPC does not respond, as it should IMHO, to -v and/or --version).

Granted for --version but for -v it does as it should: enable (any of several) verbose options. And instead of --version it has several -i(nfo) options one can use.

One might contend that --version should be (kind of) equivalent to -l, but given the plethora of options it has to (and does) support it's a little nitpicking.

While we are at it, I'd rather point out the strange lack of --help as sinonym for -h

[dbannon]

> but for -v it does as it should: enable (any of several) verbose options.

Quite correct, careless on my part.  A capital -V is sometimes used, but nowhere near 'widely'.

> several -i(nfo) options one can use.

Indeed, maybe that why I don't like it. It reminds of the awful 'info' tool, used where maintainers cannot write man pages ! 

Even -h for help is far from universal, so, maybe just  --help and --version needs to be added.  I wonder if the FPC includes a -- parser ?

Davo

[marcov]

(And away from Eric's question again, I too think its a strange omission that FPC does not respond, as it should IMHO, to -v and/or --version).

Free Pascal is not an unix program, it is portable.  The --version thingy is a GNU convention, but not otherwise enforced.

[MarkMLl]

> but for -v it does as it should: enable (any of several) verbose options.

Quite correct, careless on my part.  A capital -V is sometimes used, but nowhere near 'widely'.

Before the introduction of --version, I think that -v was used for "verbose" more often than for "version".

Going back to OP's question though, it's really very little to do with FPC output: while it's desirable to be able to report the version of build tools he specifically asked about build information pertaining to HIS PROJECT. I usually manage something like


$ zzz --version

Version 0.0 release 0 build 402
Build ID 0x13ED8078378E51CB
Checkout revision 84 2021-03-04 17:51:56Z markMLl
Built 2021-03-06 10:21:40 revision 84M
Free Pascal v3.0.4 for x86_64 Linux


but that takes a combination of extracting resources from the executable, extracting a "note" to get the build ID generated by the linker, and generating .inc files from Subversion revision information. It's all in the link I posted earlier.

MarkMLl