The linkage for the vtable for any class marked dllimport is generated as a standard external link rather than a dllimport "__imp_" link. This results in linker diagnostics such as: Info: resolving vtable for TestObject by linking to __imp___ZTV10TestObject (auto-import) d:/jsupport/mingw/bin/../lib/gcc/mingw32/4.3.3-dw2/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. The following simple testcase demonstrates this. ----- vttest.cpp ----- struct __attribute__((dllimport)) TestObject { virtual void VirtFunc(); }; int main() { TestObject obj; obj.VirtFunc(); return 0; } ----- vttestdll.cpp ----- struct __attribute__((dllexport)) TestObject { virtual void VirtFunc() {} }; > g++ -shared -o vttest.dll -Wl,--out-implib,libvttest.dll.a vttestdll.cpp Creating library file: libvttest.a > g++ -o vttest.exe vttest.cpp libvttest.dll.a Info: resolving vtable for TestObject by linking to __imp___ZTV10TestObject (auto-import) d:/jsupport/mingw/bin/../lib/gcc/mingw32/4.3.3-dw2/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
For Cygwin, we just recently made --enable-auto-import the default in CVS binutils. Now that we're moving to shared library runtimes throughout it made sense. However, I think this is a real bug, as it doesn't happen on 4.3.2; we get a direct undefined reference to the import symbol in the object file: $ g++ -g -o vttest.exe vttest.cpp libvttest.dll.a --save-temps admin@ubik /tmp/vttest $ nm vttest.o 00000000 b .bss 00000000 d .data 00000000 N .debug_abbrev 00000000 N .debug_aranges 00000000 N .debug_frame 00000000 N .debug_info 00000000 N .debug_line 00000000 N .debug_loc 00000000 N .debug_pubnames 00000000 N .debug_ranges 00000000 N .debug_str 00000000 d .eh_frame 00000000 t .text 00000000 t .text$_ZN10TestObjectC1Ev 00000000 T __ZN10TestObjectC1Ev U ___gxx_personality_v0 U ___main U __imp___ZN10TestObject8VirtFuncEv U __imp___ZTV10TestObject 00000000 T _main admin@ubik /tmp/vttest $ My earlier build of 4.3.3 with the patch for PR36654 reverted does the same thing. However, as soon as I reapplied the patch and rebuilt cc1plus, I got this output: /tmp/vttest $ nm vttest.o libvtt 00000000 b .bss 00000000 d .data 00000000 N .debug_abbrev 00000000 N .debug_aranges 00000000 N .debug_frame 00000000 N .debug_info 00000000 N .debug_line 00000000 N .debug_loc 00000000 N .debug_pubnames 00000000 N .debug_ranges 00000000 N .debug_str 00000000 d .eh_frame 00000000 t .text 00000000 t .text$_ZN10TestObjectC1Ev 00000000 T __ZN10TestObjectC1Ev U __ZTV10TestObject U ___gxx_personality_v0 U ___main U __imp___ZN10TestObject8VirtFuncEv 00000000 T _main /tmp/vttest $ So I think that confirms it.
I tested this bug for 4.5 and here it seems to be solved for i686-pc-mingw32.
I retested issue for all open branches. I can't reproduce issue anymore. Import library contains symbol for virtual. If issue still exists please provide a testcase demonstrating that issue for maintained branches still exists.
I can confirm this has been fixed. Sorry for not doing so sooner.