frederic@vangogh.cs.unc.edu (Robin Fredericksen) (03/21/90)
I am upgrading some software from C++1.2.? to C++2.0. It seems that there is something missing. At link time I get the message Undefined: __ptbl__9ih_editor__ih_editor_c *** Error code 1 Stop. and I'm not sure why. If anyone has a clue to this, PLEASE email me the solution. Thanks in advance, Eric Fredericksen internet: frederic@cs.unc.edu Computer Science Dept., Sitterson Hall csnet: frederic@unc University of North Carolina uucp: ...!mcnc!unc!frederic Chapel Hill, NC 27599-3175, USA Phone: (919) 962-1829 or 962-1932 ------------------------------------------------------------------------------- Eric Fredericksen : Insert amazingly funny or enlightening quote frederic@cs.unc.edu : in this space here. I don't need a disclaimer, I'm a graduate student so no one cares what I say...
tuck@jason.cs.unc.edu (Russ Tuck) (03/22/90)
In article <12801@thorin.cs.unc.edu> frederic@vangogh.cs.unc.edu (Robin Fredericksen) writes: >I am upgrading some software from C++1.2.? to C++2.0. It seems that >there is something missing. At link time I get the message > > Undefined: > __ptbl__9ih_editor__ih_editor_c > *** Error code 1 Does your C++ program call a routine named "ih_editor" that was compiled with plain C? If so, you need to put the declaration of "ih_editor" that C++ sees inside the {}s of extern "C" { } Just a guess. One of the main changes from 1.2 to 2.0 is type-safe linking, which means encoding argument types in the mangled names of functions to be sure the calls and the definition match (even when compiled separately) and to support overloading better. To call something C compiled, you have to tell C++ that C didn't mangle the name.
jeffw@cs.tamu.edu (Jeffrey A Waller) (03/25/90)
<tuck@jason.cs.unc.edu> writes: >article <12801@thorin.cs.unc.edu> frederic@vangogh.cs.unc.edu (Robin Frederick sen) writes: >>I am upgrading some software from C++1.2.? to C++2.0. It seems that >>there is something missing. At link time I get the message >> >> Undefined: >> __ptbl__9ih_editor__ih_editor_c >> *** Error code 1 >Does your C++ program call a routine named "ih_editor" that was compiled >with plain C? If so, you need to put the declaration of "ih_editor" that >C++ sees inside the {}s of > extern "C" { } >Just a guess. One of the main changes from 1.2 to 2.0 is type-safe >linking, which means encoding argument types in the mangled names of >functions to be sure the calls and the definition match (even when >compiled separately) and to support overloading better. To call >something C compiled, you have to tell C++ that C didn't mangle the >name. No, I don't think that that is the problem. If it is let me know. However, I have had (and still do) the same problem. Here are the error messages generated by the linker: ___ptbl__18connected__gsocket_l3: ld: inetserver.o: multiply defined ___ptbl__19fdmessager__gsocketUe: inetserver.o: multiply defined ___ptbl__18connected__gsocket_l3: inetsocket.o: multiply defined ___ptbl__19fdmessager__gsocketUe: inetsocket.o: multiply defined ___ptbl__18connected__gsocket_l3: unixclient.o: multiply defined ___ptbl__19fdmessager__gsocketUe: unixclient.o: multiply defined ___ptbl__18connected__gsocket_l3: unixserver.o: multiply defined ___ptbl__8messager__12serversoxA: unixserver.o: multiply defined ___ptbl__19fdmessager__gsocketUe: unixserver.o: multiply defined ___ptbl__18connected__gsocket_l3: unixsocket.o: multiply defined ___ptbl__19fdmessager__gsocketUe: unixsocket.o: multiply defined Concerning the symbol ___ptbl__19fdmessager__gsocketUe in inetserver.o, I looked at the c code generated by CC (2.0 that is), and after running the output through c++filt the above symbol equates to the following: Around line 164 in transformed inetserver..c extern struct __mptr* fdmessager__gsocket::_ptbl Looking on in the file, sure enough the thing is defined again: Around line 324 in transformed inetserver..c struct __mptr* fdmessager__gsocket::_ptbl = fdmessager__gsocket::_vtbl; I've never heard of ___ptbl anything although aparently it has something to due with the virtual function table, and with later experiments (described later) I think that it has something to do with multiple inheritance and virtual base classes. So, I try some stuff including +w +e1 +e0 compiler options, but the error messages remain unaffected. At this point let me digress (still further) and give the original class inheritance scheme. class messager // classes that pass messages around class fdmessager: public virtual messager // ditto, except by file descriptors class taggedio: public virtual messager // a certian protocol of messageing class connected // classes referring to same thing form linked list class gsocket:public fdmessager,public taggedio,public connected class inetsocket:public virtual gsocket class unixsocket:public virtual gsocket class clientsocket:public virtual gsocket class serversocket:public virtual gsocket class inetserver:public inetsocket,public serversocket class unixserver:public unixsocket,public serversocket class inetclient:public inetsocket,public clientsocket class unixserver:public unixsocket,public clientsocket So for some reson--grasping at straws-- I change the definition of gsocket a little, and THAT IS ALL THAT WAS CHANGED, to the following class gsocket:public virtual fdmessager,public virtual taggedio,public connected Suddenly the new linker error messages are the following: ___ptbl__10fdmessager__10inetsUt: ld: inetsocket.o: multiply defined ___ptbl__8messager__12serversoxA: unixserver.o: multiply defined ___ptbl__8taggedio__12serversoxA: unixserver.o: multiply defined ___ptbl__10fdmessager__10unixsxd: unixsocket.o: multiply defined This is my first forray into multiple inheritance so I havn't the foggiest how to fix things. I someone has similar problems, or at least more experience please let me know. e-mail: jeffw@cssun.tamu.edu