This PR is to track the existence of some issues concerning the --help and --version output of various programs in GCC. The --help and --version output of various parts of GCC does not follow the GNU coding standards. For details, see: http://gcc.gnu.org/ml/gcc/2000-10/msg00382.html Release: 2.97 20001028 (experimental) Environment: System: Linux decomino 2.2.17 #1 Mon Sep 4 20:22:16 UTC 2000 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu How-To-Repeat: gcov --help and gcov --version are obvious problems (gcov doesn't handle long options). In general, run all programs installed as part of GCC with --help and --version and compare to what the GNU coding standards say the output should look like.
State-Changed-From-To: open->analyzed State-Changed-Why: Confirming my own PR.
From: jsm28@gcc.gnu.org To: gcc-gnats@gcc.gnu.org, jsm28@cam.ac.uk, nobody@gcc.gnu.org Cc: Subject: Re: other/704 Date: 20 May 2001 00:26:33 -0000 Synopsis: --help and --version State-Changed-From-To: open->analyzed State-Changed-By: jsm28 State-Changed-When: Sat May 19 17:26:33 2001 State-Changed-Why: Confirming my own PR. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=704&database=gcc
From: jsm28@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: other/704 Date: 1 Nov 2001 21:48:50 -0000 CVSROOT: /cvs/gcc Module name: gcc Changes by: jsm28@gcc.gnu.org 2001-11-01 13:48:50 Modified files: gcc : ChangeLog Makefile.in gcov.c gcc/doc : gcov.texi Log message: * Makefile.in (GCOV_OBJS): Add version.o. * gcov.c: Include "version.h" and <getopt.h>. (gcov_version_string): Remove. (print_usage): Take a parameter to determine whether this is a call from --help or an error message. Give fuller output that follows the GNU Coding Standards for --help. (print_version): New function. (options): New. (process_args): Use getopt_long. Support long options. Follow GNU Coding Standards for --help and --version. * doc/gcov.texi: Document long options. Addresses part of PR other/704. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.11728&r2=1.11729 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.761&r2=1.762 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcov.c.diff?cvsroot=gcc&r1=1.38&r2=1.39 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/gcov.texi.diff?cvsroot=gcc&r1=1.5&r2=1.6
From: jsm28@gcc.gnu.org To: gcc-gnats@gcc.gnu.org Cc: Subject: other/704 Date: 8 Jan 2002 10:00:28 -0000 CVSROOT: /cvs/gcc Module name: gcc Changes by: jsm28@gcc.gnu.org 2002-01-08 02:00:28 Modified files: gcc : ChangeLog gcc.c gcc/f : ChangeLog g77spec.c Log message: * gcc.c (option_map): Remove --version. (process_command): Handle -fversion following the GNU Coding Standards. Partially addresses PR other/704. f: * g77spec.c (lookup_option): Handle -fversion. (lang_specific_driver): Update copyright date in --version output. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.12591&r2=1.12592 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gcc&r1=1.284&r2=1.285 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/f/ChangeLog.diff?cvsroot=gcc&r1=1.416&r2=1.417 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/f/g77spec.c.diff?cvsroot=gcc&r1=1.35&r2=1.36
Joseph, is this bug fully fixed? c++filt - no longer included gccbug: gccbug (GCC) 3.4 20030527 (experimental) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcjh: gcjh (GCC) 3.4 20030527 (experimental) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcov: gcov 304e (GCC 3.4 20030527 (experimental)) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jcf-dump: jcf-dump (GCC) 3.4 20030527 (experimental) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jv-scan: jv-scan (GCC) 3.4 20030527 (experimental) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc: gcc (GCC) 3.4 20030527 (experimental) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcj: gcj (GCC) 3.4 20030527 (experimental) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. g77: GNU Fortran (GCC) 3.4 20030527 (experimental) Copyright (C) 2002 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING or type the command `info -f g77 Copying'. g++: g++ (GCC) 3.4 20030527 (experimental) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. cpp: cpp (GCC) 3.4 20030527 (experimental) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jar: (this one right?) jar (fastjar) 0.92-gcc Copyright 1999, 2000, 2001 Bryan Burns Copyright 2002 Free Software Foundation This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rmic: rmic (GNU libgcj) 3.4 20030527 (experimental) Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rmiregistry: rmiregistry (GNU libgcj) 3.4 20030527 (experimental) Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. addr2name.awk: prints out awk's version (is there a way to fix this one?) Also I did not check the Ada's programs.
Subject: Re: --help and --version On Wed, 27 May 2003, pinskia@physics.uc.edu wrote: > Joseph, is this bug fully fixed? Is what you've given a full list of executables installed in bindir by GCC (apart from Ada which has a separate bug report, 4720)? I don't see jv-convert in there. Roger Sayle pointed out the problem applies to the host-and-target-specific mips-tfile, mips-tdump programs, and I don't think his patch <http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01832.html> has been reviewed. > gcov: > gcov 304e (GCC 3.4 20030527 (experimental)) This is not the correct format for a program with its own separate version number. And who thought it was a good idea to give gcov its own version number again anyway (on basic-improvements-branch, I think), when it's just a part of GCC? > jar: (this one right?) > jar (fastjar) 0.92-gcc I think this one is right, for the tricky case of a program imported from elsewhere then abandoned upstream. > addr2name.awk: prints out awk's version (is there a way to fix this one?) So, this one is still buggy; if it should be installed at all, it should have proper --help and --version output.
Yep this is still a problem. Also here is jv-convert 's output: jv-convert --version jv-convert (GNU libgcj) 3.4 20030601 (experimental) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jv-convert --help (just runs forever).
To summarize: the remaining problems are jv-convert --help runs forever addr2name.awk gives awk's version number gcov has its own version number, and shouldn't mips-tfile and mips-tdump don't handle --version or --help correctly I think each of these should be given its own bug and this one should be closed. But I'm not about to do it right now.
The Ada version of this bug is filed under PR 4720.
The java program's --help is in bug 5303.
According to the AVR target, gcov has the same version number as GCC for 3.3.2: gcov (GCC) 3.3.2 Copyright (C) 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
From what is left in comment #8 by Nathanael Nerode: jv-convert: is covered by bug #5303 addr2name.awk: is covered by bug #5303 mips-tfile and mips-tdump: these look like what is left and then can this bug can be closed? Can anybody verify these?
gcc-ar, gcc-nm, and gcc-ranlib all fail for me when passed --help or --version like this: /usr/local/bin/gcc-ranlib: Cannot find plugin 'liblto_plugin.so' IMO the --help or --version output should be printed before looking for the plugin.
(In reply to Eric Gallager from comment #13) > gcc-ar, gcc-nm, and gcc-ranlib all fail for me when passed --help or > --version like this: > > /usr/local/bin/gcc-ranlib: Cannot find plugin 'liblto_plugin.so' > > IMO the --help or --version output should be printed before looking for the > plugin. Iain Sandoe has a patch for this: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01104.html
Author: iains Date: Wed Aug 22 12:12:46 2018 New Revision: 263768 URL: https://gcc.gnu.org/viewcvs?rev=263768&root=gcc&view=rev Log: Make the gcc-ar,nm, strip tools respond correctly to --help and --version when there's no plugin built. gcc/ PR other/704 * gcc-ar.c (main): Don’t try to invoke the plug-in if we’re not building it. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc-ar.c
(In reply to Iain Sandoe from comment #15) > Author: iains > Date: Wed Aug 22 12:12:46 2018 > New Revision: 263768 > > URL: https://gcc.gnu.org/viewcvs?rev=263768&root=gcc&view=rev > Log: > Make the gcc-ar,nm, strip tools respond correctly to --help and --version > when there's no plugin built. > > gcc/ > > PR other/704 > * gcc-ar.c (main): Don’t try to invoke the plug-in if we’re not > building it. > > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/gcc-ar.c So can this be closed now?
(In reply to Eric Gallager from comment #16) > (In reply to Iain Sandoe from comment #15) > > Author: iains > > Date: Wed Aug 22 12:12:46 2018 > > New Revision: 263768 > > > > URL: https://gcc.gnu.org/viewcvs?rev=263768&root=gcc&view=rev > > Log: > > Make the gcc-ar,nm, strip tools respond correctly to --help and --version > > when there's no plugin built. > > > > gcc/ > > > > PR other/704 > > * gcc-ar.c (main): Don’t try to invoke the plug-in if we’re not > > building it. > > > > > > Modified: > > trunk/gcc/ChangeLog > > trunk/gcc/gcc-ar.c > > So can this be closed now? WAITING on a reply
Whether this is fixed may be determined by running all of the programs installed in $exec_prefix/bin by current mainline with the --help and --version options (and confirming the GCC version number is properly shown in the --version output).
(In reply to joseph@codesourcery.com from comment #18) > Whether this is fixed may be determined by running all of the programs > installed in $exec_prefix/bin by current mainline with the --help and > --version options (and confirming the GCC version number is properly shown > in the --version output). looks like gcc-nm and gcc-ranlib still fail with --help: $ /usr/local/bin/gcc-nm --help error: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/nm: invalid argument -- Usage: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/nm [-agnopruUmxjlfAP[s segname sectname] [-] [-t format] [[-arch <arch_flag>] ...] [file ...] $ /usr/local/bin/gcc-ranlib --help error: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/ranlib: unknown option character `-' in: --help Usage: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/ranlib [-sactfqLT] [-] archive [...] $ /usr/local/bin/x86_64-apple-darwin10.8.0-gcc-nm --help error: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/nm: invalid argument -- Usage: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/nm [-agnopruUmxjlfAP[s segname sectname] [-] [-t format] [[-arch <arch_flag>] ...] [file ...] $ /usr/local/bin/x86_64-apple-darwin10.8.0-gcc-ranlib --help error: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/ranlib: unknown option character `-' in: --help Usage: /opt/iains/x86_64-apple-darwin10/darwin-gcc-5-3r0/bin/ranlib [-sactfqLT] [-] archive [...] $
(In reply to Eric Gallager from comment #19) > (In reply to joseph@codesourcery.com from comment #18) > > Whether this is fixed may be determined by running all of the programs > > installed in $exec_prefix/bin by current mainline with the --help and > > --version options (and confirming the GCC version number is properly shown > > in the --version output). > > looks like gcc-nm and gcc-ranlib still fail with --help: That's not a fault with the GCC wrappers, it's because the "upstream" cctools nm and ranlib don't respond to "--help" (or --version). I have amended versions of them that handle --help and --version (available on github***) that work: $ ./gcc/gcc-ar --help usage: ar -d [-TLsv] archive file ... ar -m [-TLsv] archive file ... <snip> $ ./gcc/gcc-ar --version xtools-1.1.0 ar - the point is that this is not a problem with the GCC wrappers, the intention of them is to pass the --help and --version onto the underlying commands. From the point of view of Darwin, I'd say this could be closed, of course it might not be completely clean for other platforms. *** Note: the versions published on github are quite old - on the TODO to provide some updates.
(In reply to Iain Sandoe from comment #20) > (In reply to Eric Gallager from comment #19) > > (In reply to joseph@codesourcery.com from comment #18) > > > Whether this is fixed may be determined by running all of the programs > > > installed in $exec_prefix/bin by current mainline with the --help and > > > --version options (and confirming the GCC version number is properly shown > > > in the --version output). > > > > looks like gcc-nm and gcc-ranlib still fail with --help: > > That's not a fault with the GCC wrappers, it's because the "upstream" > cctools nm and ranlib don't respond to "--help" (or --version). I have > amended versions of them that handle --help and --version (available on > github***) that work: > > $ ./gcc/gcc-ar --help > usage: ar -d [-TLsv] archive file ... > ar -m [-TLsv] archive file ... > <snip> > > $ ./gcc/gcc-ar --version > xtools-1.1.0 ar > > - the point is that this is not a problem with the GCC wrappers, the > intention of them is to pass the --help and --version onto the underlying > commands. > > From the point of view of Darwin, I'd say this could be closed, of course it > might not be completely clean for other platforms. > > *** Note: the versions published on github are quite old - on the TODO to > provide some updates. OK, closing then.
(In reply to Eric Gallager from comment #21) > (In reply to Iain Sandoe from comment #20) > > (In reply to Eric Gallager from comment #19) > > > (In reply to joseph@codesourcery.com from comment #18) > > > > Whether this is fixed may be determined by running all of the programs > > > > installed in $exec_prefix/bin by current mainline with the --help and > > > > --version options (and confirming the GCC version number is properly shown > > > > in the --version output). > > > > > > looks like gcc-nm and gcc-ranlib still fail with --help: > > > > That's not a fault with the GCC wrappers, it's because the "upstream" > > cctools nm and ranlib don't respond to "--help" (or --version). I have > > amended versions of them that handle --help and --version (available on > > github***) that work: > > > > $ ./gcc/gcc-ar --help > > usage: ar -d [-TLsv] archive file ... > > ar -m [-TLsv] archive file ... > > <snip> > > > > $ ./gcc/gcc-ar --version > > xtools-1.1.0 ar > > > > - the point is that this is not a problem with the GCC wrappers, the > > intention of them is to pass the --help and --version onto the underlying > > commands. > > > > From the point of view of Darwin, I'd say this could be closed, of course it > > might not be completely clean for other platforms. > > > > *** Note: the versions published on github are quite old - on the TODO to > > provide some updates. > > OK, closing then. Opened an issue on GitHub for your version of cctools about this: https://github.com/iains/darwin-xtools/issues/3