If g++ is called with -V option and the only input files are objects and libraries, then the alternative driver called in chain cannot guess the language any more, forgets to put libstdc++ in the collect2 call, and the linker fails. Release: 3.3, 3.4 (snapshots) Environment: gcc version 3.3 20030506 (prerelease); gcc version 3.4 20030509 (experimental); platform-independent How-To-Repeat: Take a little C++ (Hello, world!) program, compile and link it separately, specifying the -V option in both commands.
Fix: Probably, the installation script could create an extra hardlink 'machine-g++-version'; the driver could then insert its basename into the execvp() first argument instead of fixed '-gcc-'. Or give along a -x option depending on the own basename.
confirmed on mainline 20030524)/3.3 experimental (20021216): tin:~/src/gnu/gcctest>g++ -V3.3 testhello.cc -v Reading specs from /home/gates/pinskia/linux/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Configured with: /home/gates/pinskia/src/gnu/gcc/src/configure --target=i686-pc-linux- gnu --enable-__cxa_atexit --prefix=/home/gates/pinskia/linux --enable-threads=posix -- enable-shared Thread model: posix gcc version 3.3 20021216 (experimental) /home/gates/pinskia/linux/lib/gcc-lib/i686-pc-linux-gnu/3.3/cc1plus -quiet -v - D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 - D_GNU_SOURCE testhello.cc -D__GNUG__=3 -quiet -dumpbase testhello.cc -auxbase testhello -version -o /tmp/ccNsI82O.s GNU C++ version 3.3 20021216 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 3.3 20021216 (experimental). #include "..." search starts here: #include <...> search starts here: /home/gates/pinskia/linux/include/c++/3.3 /home/gates/pinskia/linux/include/c++/3.3/i686-pc-linux-gnu /home/gates/pinskia/linux/include/c++/3.3/backward /usr/local/include /home/gates/pinskia/linux/include /home/gates/pinskia/linux/lib/gcc-lib/i686-pc-linux-gnu/3.3/include /home/gates/pinskia/linux/i686-pc-linux-gnu/include /usr/include End of search list. /home/gates/pinskia/linux/lib/gcc-lib/i686-pc-linux-gnu/3.3/../../../../i686-pc-linux-gnu/bin/ as -V -Qy -o /tmp/ccXwuSGD.o /tmp/ccNsI82O.s GNU assembler version 2.14.90 (i686-pc-linux-gnu) using BFD version 2.14.90 20030523 /home/gates/pinskia/linux/lib/gcc-lib/i686-pc-linux-gnu/3.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /home/gates/pinskia/ linux/lib/gcc-lib/i686-pc-linux-gnu/3.3/crtbegin.o -L/home/gates/pinskia/linux/lib/gcc-lib/ i686-pc-linux-gnu/3.3 -L/home/gates/pinskia/linux/lib/gcc-lib/i686-pc-linux-gnu/3.3/../../../../ i686-pc-linux-gnu/lib -L/home/gates/pinskia/linux/lib/gcc-lib/i686-pc-linux-gnu/3.3/../../.. / tmp/ccXwuSGD.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /home/gates/pinskia/linux/lib/gcc-lib/ i686-pc-linux-gnu/3.3/crtend.o /usr/lib/crtn.o /tmp/ccXwuSGD.o(.text+0x1b): In function `main': : undefined reference to `std::cout' /tmp/ccXwuSGD.o(.text+0x20): In function `main': : undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' /tmp/ccXwuSGD.o(.text+0x49): In function `__static_initialization_and_destruction_0(int, int)': : undefined reference to `std::ios_base::Init::Init[in-charge]()' /tmp/ccXwuSGD.o(.text+0x7a): In function `__tcf_0': : undefined reference to `std::ios_base::Init::~Init [in-charge]()' /tmp/ccXwuSGD.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit status tin:~/src/gnu/gcctest>g++ -v Reading specs from /home/gates/pinskia/linux/lib/gcc-lib/i686-pc-linux-gnu/3.4/specs Configured with: /home/gates/pinskia/src/gnu/gcc/src/configure --target=i686-pc-linux- gnu --enable-__cxa_atexit --prefix=/home/gates/pinskia/linux --enable-threads=posix -- enable-shared Thread model: posix gcc version 3.4 20030524 (experimental) tin:~/src/gnu/gcctest>
While the PR is certainly valid, -V is not really the recommended way anymore to use different compilers. It was used, IIRC, in the time frame of before gcc2.8 or so, and indeed the manual entry for -V gives revealing clues about when this was useful: @item -V @var{version} @opindex V The argument @var{version} specifies which version of GCC to run. This is useful when multiple versions are installed. For example, @var{version} might be @samp{2.0}, meaning to run GCC version 2.0. @end table The way to go these days is to install different versions of gcc into different directories. I have the feeling that this will some day be "fixed" by obsoleting -V... W.
*** Bug 11143 has been marked as a duplicate of this bug. ***
Or under different names (via program_transform_name), which is actually quite feasible. I'm suspending this, since it's not going to be fixed in the forseeable future (except by obsoleting -V, which has been discussed).
-V was removed for a while (I forgot when) but it was put back and fixed up so it would work between 3.x's but it also has been not recommened to use -V any way.
*** Bug 13036 has been marked as a duplicate of this bug. ***
*** Bug 14825 has been marked as a duplicate of this bug. ***
*** Bug 15940 has been marked as a duplicate of this bug. ***
*** Bug 17375 has been marked as a duplicate of this bug. ***
*** Bug 19504 has been marked as a duplicate of this bug. ***
-b and -V were removed: 2010-04-08 Manuel López-Ibáñez <manu@gcc.gnu.org> PR 42485 * doc/invoke.texi (-b,-V): Delete. * doc/tm.texi: Do not mention -b. * gcc.c (display_help): Delete -b and -V. (process_command): Delete -b and -V. * gcc.h (DEFAULT_SWITCH_TAKES_ARG): Delete -b and -V.