Re: is there a way to find out gfortran version and/or options from a given binary?

[Arjen Markus <arjen.markus895@gmail.com>]

Hi Kay,

(you forgot to reply to everybody ;))

I am using a Windows version of gfortran and strings. I use a file viewer
that comes with the Total Commander file manager. So, it may be something
specific to that version of strings.

Regards,

Arjen

Op vr 3 jun. 2022 om 09:25 schreef Kay Diederichs <
kay.diederichs@uni-konstanz.de>:

> On 6/3/22 08:47, Arjen Markus via Fortran wrote:
> > Do you know why the strings command does not show the identification
> > string,
> > which clearly present in the executable file, even though it should
> examine
> > the
> > entire file (the --all option does not alter the output)?
> >
> > Regards,
> >
> > Arjen
> >
> > Op vr 3 jun. 2022 om 07:22 schreef Janne Blomqvist <
> > blomqvist.janne@gmail.com>:
> >
> >> On Thu, Jun 2, 2022 at 10:33 PM Kay Diederichs
> >> <kay.diederichs@uni-konstanz.de> wrote:
> >>> Am 02.06.22 um 21:06 schrieb Janne Blomqvist:
> >>>> As an alternative approach, make a command-line option (say, "-v")
> >>>> that prints the version number of the program, name of the author and
> >>>> other pertinent information, as well as the output of
> >>>> compiler_version() and compiler_options(), and then exits. That would
> >>>> ensure that those calls won't be optimized away.
> >>>>
> >>>
> >>> I was thinking of such a -v option as well, and it is a solution for
> >>> some situations, but not e.g. for a dynamically loadable library (see
> >>> https://cims.nyu.edu/~donev/Fortran/DLL/DLL.Forum.txt ) which is my
> >>> situation (
> >>> https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/LIB ). I'd
> >>> like to be able to see later which compiler version and options were
> >>> used when compiling that library, because over the years of
> distributing
> >>> this code, compilers and options have been changing.
> >>
> >> For the library case, can't you make a function
> >> libraryname_print_version_info() or whatever you want to call it that
> >> does the same? Of course, if the user never calls that function, uses
> >> a static library, and everything is compiled with -ffunction-sections
> >> and linked with --gc-sections that will not work, but otherwise the
> >> string should still be there in the binary so you should be able to
> >> find it with the strings tool?
> >>
> >>> -g includes the source code, which is not always desired, and is not
> >>> possible here due to license issues - there was no concept of "open
> >>> source" as we have it today in the 80ies when this code was started.
> >>
> >> Hmm, maybe that's the case, I don't have a legal opinion to offer on
> >> this, sorry.
> >>
> >>> Also I think it makes the code slower.
> >>
> >> No, at least with GCC -g doesn't affect the code generation. It makes
> >> the binary bigger so it takes longer to copy around, and depending on
> >> how the debug info is spread out in the binary some of that might be
> >> unnecessarily mapped into memory when running, but I think you'd be
> >> very hard pressed to measure any difference in performance.
> >>
> >> --
> >> Janne Blomqvist
> >>
> >
>
> Arjen,
>
> "egrep"-ing for 'GNU|GCC' in the "strings" output shows more than
> "grep"-ing for GNU, which is what I tried first.
> But I don't think you see even more with a "fileviewer" (which do you
> refer to?
> I tried the "bless" hex editor and "okteta"; they don't show more than
> "strings").
>
> @Janne thanks for pointing out that -g does not make the code slower.
> Is there an option that prevents the sourcecode to be included when -g is
> used?
>
> thanks,
> Kay
>