public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Janne Blomqvist <blomqvist.janne@gmail.com>
To: Kay Diederichs <kay.diederichs@uni-konstanz.de>
Cc: Arjen Markus <arjen.markus895@gmail.com>,
	Andre Vehreschild <vehre@gmx.de>,
	Fortran List <fortran@gcc.gnu.org>
Subject: Re: is there a way to find out gfortran version and/or options from a given binary?
Date: Fri, 3 Jun 2022 08:22:30 +0300	[thread overview]
Message-ID: <CAO9iq9FLgJrjXatbUBCG251koddPLK_Ma=cQiJmmiop6NHxsKA@mail.gmail.com> (raw)
In-Reply-To: <e25d7b2f-e8f1-20e0-0374-09c7fd75d131@uni-konstanz.de>

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

  reply	other threads:[~2022-06-03  5:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01  8:42 Kay Diederichs
2022-06-01  9:30 ` Arjen Markus
2022-06-01  9:41   ` Kay Diederichs
2022-06-01  9:50     ` Andre Vehreschild
2022-06-01  9:53       ` Arjen Markus
2022-06-01 10:00         ` Arjen Markus
2022-06-01 10:16           ` Kay Diederichs
2022-06-01 11:36             ` Arjen Markus
2022-06-01 11:46               ` Arjen Markus
2022-06-01 12:04                 ` Kay Diederichs
2022-06-01 12:19                   ` Arjen Markus
2022-06-02 19:06             ` Janne Blomqvist
2022-06-02 19:33               ` Kay Diederichs
2022-06-03  5:22                 ` Janne Blomqvist [this message]
2022-06-03  6:47                   ` Arjen Markus
     [not found]                     ` <14d31069-82ab-5a7a-2f35-15411da30141@uni-konstanz.de>
2022-06-03  7:30                       ` Arjen Markus
2022-06-03  8:16                         ` Janne Blomqvist
2022-06-03 10:12                           ` Kay Diederichs
2022-06-03 10:12                             ` Kay Diederichs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO9iq9FLgJrjXatbUBCG251koddPLK_Ma=cQiJmmiop6NHxsKA@mail.gmail.com' \
    --to=blomqvist.janne@gmail.com \
    --cc=arjen.markus895@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=kay.diederichs@uni-konstanz.de \
    --cc=vehre@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).