Attached C++ code contains a pure virtual function, unpack(), and a a templated function of the same name (but with different arguments). The presence of the templated function causes linking to fail. Changing the name of the templated function results in successful linking. Implementing the unmarshal() (which calls the pure virtual function, which should result in a call to unpack() implemented in the derived class) function in the header also allows for successful linking, but I think this only hides the bug.
Steps to Reproduce: 1. g++ -Wall -ansi -pedantic -I. -o boog boog.cc 2. Linking will fail with the message above. 3. Change "unpack" to something else (grep for FIXME). 4. Repeat 1. Linking succeeds.
Created attachment 4424 [details] First cut at code that shows the bug (source file)
Created attachment 4425 [details] Code for showing bug (goes with boog.cc)
Created attachment 4426 [details] Similar code for showing bug Courtesy of Gerhard Esterhuizen <gesterhuizen@yahoo.com>. Nicely shows the "workaround" of implementing the calling function in the header (but this doesn't always seem to work in my experience).
Also filed bug at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99236 but jakub@redhat.com didn't seem very responsive. Version info from gcc -v: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Same bug seems to exist in gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7).
Created attachment 4427 [details] Preprocessed output for boog
Created attachment 4428 [details] Preprocessed output for boog2
I can reproduce this on 3.2.3 but in 3.3.1 (20030707), gcc is already fixed. It is most likely fixed in 3.3 but for sure it is fixed in 3.3.1 which will be release in the next two weeks.