Re: is there a way to find out gfortran version and/or options from a given binary?
On Wed, Jun 1, 2022 at 1:16 PM Kay Diederichs wrote: > If -g is used, the executable _always_ has version and option info Well, isn't that the answer to your question then? 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. -- Janne Blomqvist
Re: is there a way to find out gfortran version and/or options from a given binary?
Am 02.06.22 um 21:06 schrieb Janne Blomqvist: On Wed, Jun 1, 2022 at 1:16 PM Kay Diederichs wrote: If -g is used, the executable _always_ has version and option info Well, isn't that the answer to your question then? 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. -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. Also I think it makes the code slower. Using strings | grep GCC I get meaningful output when e.g. -O2 is used as compiler option, but not for other options. I don't understand it yet which is why I wish there were a dedicated compiler option for including the compilation line in the binary (like -sox for ifort). Best, Kay -- Kay Diederichshttp://strucbio.biologie.uni-konstanz.de email: kay.diederi...@uni-konstanz.de Tel +49 7531 88 4049 Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz This e-mail is digitally signed. If your e-mail client does not have the necessary capabilities, just ignore the attached signature "smime.p7s". smime.p7s Description: S/MIME Cryptographic Signature
Re: is there a way to find out gfortran version and/or options from a given binary?
On Thu, Jun 2, 2022 at 10:33 PM Kay Diederichs 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
Re: is there a way to find out gfortran version and/or options from a given binary?
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.ja...@gmail.com>: > On Thu, Jun 2, 2022 at 10:33 PM Kay Diederichs > 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 >
