[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 --- Comment #22 from Eric Gallager --- (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 jos...@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 ... > > > > > > $ ./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
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from Eric Gallager --- (In reply to Iain Sandoe from comment #20) > (In reply to Eric Gallager from comment #19) > > (In reply to jos...@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 ... > > > $ ./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.
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 --- Comment #20 from Iain Sandoe --- (In reply to Eric Gallager from comment #19) > (In reply to jos...@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 ... $ ./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.
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2006-02-02 13:45:08 |2019-2-22 --- Comment #19 from Eric Gallager --- (In reply to jos...@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 ] ...] [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 ] ...] [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 [...] $
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 --- Comment #18 from joseph at codesourcery dot com --- 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).
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING --- Comment #17 from Eric Gallager --- (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
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 --- Comment #16 from Eric Gallager --- (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?
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 --- Comment #15 from Iain Sandoe --- 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
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-08/msg01104.ht ||ml CC||iains at gcc dot gnu.org --- Comment #14 from Eric Gallager --- (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
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #13 from Eric Gallager --- 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.
[Bug other/704] --help and --version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704 Bug 704 depends on bug 5303, which changed state. Bug 5303 Summary: Undocumented java programs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5303 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX
