I use gcc (GCC) 4.2.0 20060120 to compile Cactus, a large piece of code combining C, C++, and Fortran. I receive many errors from the linker like /usr/bin/ld: multiple definitions of symbol typeinfo for MPI::Op /Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_Carpet.a(helpers.cc.o) definition of typeinfo for MPI::Opin section (__DATA,__const) /Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_CarpetAdaptiveRegrid.a(CAR.cc.o) definition of typeinfo for MPI::Opin section (__DATA,__const) or /usr/bin/ld: multiple definitions of symbol vtable for MPI::Op /Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_Carpet.a(helpers.cc.o) definition of vtable for MPI::Opin section (__DATA,__const) /Users/eschnett/Calpha/configs/einstein-orange-gcc-debug/lib/libthorn_CarpetAdaptiveRegrid.a(CAR.cc.o) definition of vtable for MPI::Opin section (__DATA,__const) (Note that the error messages seem run-together; e.g. "MPI::OPin" seems to refer to the class "MPI::Op", which is located IN a certain section.) These errors are not there with gcc (GCC) 4.2.0 20051129. The code also works fine on many other architectures. But with C++, I am not sure what the reason is. I have looked on the web, and the gcc PR "[Bug c++/16218] Link problems with inline virtual function in multiple translation units" seems similar. At that time, it apparently was an error in gcc that caused this problem. I use the linker /usr/bin/ld Apple Computer, Inc. version cctools-590.18.obj~10 and these C++ classes are defined in LAM MPI 7.0.6-11, which I installed via fink.
Do you have a simple example?
Here is a way to reproduce the error with very little source code, but still depending on the LAM MPI library. The actual source code I used consists of two files, main.cc and sub.cc, which I include here for completeness: main.cc: #include <mpi.h> int main (int argc, char * argv[]) { return 0; } sub.cc: #include <mpi.h> void sub () { } I preprocessed these with "g++ -E", and I attach the results. When I compile the preprocessed sources, I get: $ ~/gcc-new/bin/g++ -o lamtest main.ii sub.ii /usr/bin/ld: multiple definitions of symbol typeinfo for MPI::Op /var/tmp//ccFSbBVd.o definition of typeinfo for MPI::Opin section (__DATA,__const) /var/tmp//cc8Rm38U.o definition of typeinfo for MPI::Opin section (__DATA,__const) /usr/bin/ld: multiple definitions of symbol typeinfo for PMPI::Op /var/tmp//ccFSbBVd.o definition of typeinfo for PMPI::Opin section (__DATA,__const) /var/tmp//cc8Rm38U.o definition of typeinfo for PMPI::Opin section (__DATA,__const) /usr/bin/ld: multiple definitions of symbol typeinfo for PMPI::Comm /var/tmp//ccFSbBVd.o definition of typeinfo for PMPI::Commin section (__DATA,__const) /var/tmp//cc8Rm38U.o definition of typeinfo for PMPI::Commin section (__DATA,__const) (and many more warnings like that).
Created attachment 10715 [details] Gzipped preprocessed failing source code, part 1
Created attachment 10716 [details] Gzipped preprocessed failing source code, part 2
I think that is enough to reproduce it for now. Thanks, when my computer (laptop) gets back up and working, I will look into this. I think this was caused by the section changes.
Trying to reduce this failure. (I can reproduce it on today's compiler).
Reduced testcase: file1.cc: class f { virtual void g(); }; inline void f::g() {} int sub(void) {} file2.cc: class f { virtual void g(); }; inline void f::g() {} int main(void) {} ------ Now why does this work if I add inline to the method inside the declaration of the class.
Hmm, this testcase works correctly on x86_64-linux-gnu, in that the vtable is marked as weak.
Just to clarify with "gcc (GCC) 4.2.0 20051129", you were able to compile the example you gave in comment #2?
Yes, I am able to compile the code with that version: $ ~/gcc/bin/g++ --version g++ (GCC) 4.2.0 20051129 (experimental) $ ~/gcc/bin/g++ -o lamtest *.ii -L/sw/lib -llammpio -llammpi++ -lmpi -llam
It was broken before "20051231". So we are done to a month.
It worked in "20051203".
It was broken in "20051217". so only two weeks now.
Nathan sorry for CCing you (that was accident).
Fails in "20051210".
Before the breakage: .globl __ZTV1f .weak_definition __ZTV1f .section __DATA,__const_coal,coalesced After: .globl __ZTV1f .const_data We are doing two things wrong, not marking this as weak and then not putting it into the coalesced section.
Caused by: (machopic_select_section): Return the selected section rather than emitting assembly code. Replace the static function table with inline conditional expressions. Update the tests of last_text_section and move them into the FUNCTION_DECL block. I have to figure out why.
Or maybe not. More likely the TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT changes.
I might need some C++ help on this one but I think this is valid as the virtual function is marked as inline so it is vague but can that be a key function?
Found the problem and a way to fix it. The problem is that the key function needs to be changed to the arm-eabi way and not the IA64 C++ ABI way. See http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02645.html for the ARM-eabi way.
To remind me, I should enable g++.dg/abi/key1.C on *-darwin.
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01843.html
I am no longer going to work on this, it is too much hassle for me to get this fixed.
Submitted patch to fix this http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01705.html
Subject: Bug 25908 Author: mrs Date: Thu Mar 2 02:20:54 2006 New Revision: 111632 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111632 Log: PR darwin/25908 * decl2.c (import_export_decl): Fix ABI breakage on darwin. * g++.dg/abi/key2.C: Add. Added: trunk/gcc/testsuite/g++.dg/abi/key2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
Fixed, thanks Mike for fixing this one.