Undefined Reference Errors?

I am having compilation linker issues and am looking for an explanation as to what is causing the error and how to fix it. The declaration of header files it is looking for all seem to be in the correct location and included properly, however I may be wrong.

1
2
3
CMakeFiles/SONNE1.dir/src/myPhysListIon.cc.o: In function `G4LElastic::G4LElastic()':
myPhysListIon.cc:(.text._ZN10G4LElasticC1Ev[G4LElastic::G4LElastic()]+0x43): 
undefined reference to `vtable for G4LElastic'
We'd need to see the actual code for G4LElastic to be sure. It looks as though you've defined your class such that the compiler thinks it should have a vtable, i.e. you've declared some virtual methods, but that you haven't actually defined those methods in such a way as a vtable is created.

I think I've seen this before when you have an abstract or interface class that's missing a definition for the constructor and/or destructor. Could that be it?
Here is the class, I am unsure if that is the problem however as many if not all of the invoked classes seem to be returning undefined reference errors, perhaps it is something to do with the system or Makefile linker invocation?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#ifndef G4LElastic_h
#define G4LElastic_h 1

class G4LElastic : public G4HadronicInteraction
{
public:

   G4LElastic() : G4HadronicInteraction("G4LElastic")
   {
      SetMinEnergy( 0.0*GeV );
      SetMaxEnergy( DBL_MAX );
   }

   ~G4LElastic() {};
 
   G4HadFinalState * ApplyYourself(const G4HadProjectile & aTrack, 
                                    G4Nucleus & targetNucleus);

private:


   G4LightMedia LightMedia;

   G4int Rtmi(G4double* x, G4double xli, G4double xri, G4double eps, 
              G4int iend,
              G4double aa, G4double bb, G4double cc, G4double dd, 
              G4double rr);

   G4double Fctcos(G4double t, 
                   G4double aa, G4double bb, G4double cc, G4double dd, 
                   G4double rr);

   void Defs1(G4double p, G4double px, G4double py, G4double pz, 
              G4double pxinc, G4double pyinc, G4double pzinc, 
              G4double* pxnew, G4double* pynew, G4double* pznew);
};
#endif 
@helios, checking on the stackoverflow solution, however I am wondering if this is a system environmental problem or perhaps the Makefile needs added lines to specify linking options.
via,

https://gcc.gnu.org/faq.html#vtables

which is a reference from the preferred fix in the stackoverflow comment suggested by @helios, it is suggested:

"Therefore, if you fail to define this particular method, the linker may complain about the lack of definitions for apparently unrelated symbols. Unfortunately, in order to improve this error message, it might be necessary to change the linker, and this can't always be done.

The solution is to ensure that all virtual methods that are not pure are defined. Note that a destructor must be defined even if it is declared pure-virtual"


By 'changing the linker' do they mean using a different version of the linker utility ld in my case?
This is how I interpret that bit:
in order to make this error message easier to understand for the user, we (the toolchain developers) might need to change the linker
So the solution then is to add a definition to the constructor/destructor to the broken classes, what does that imply necessarily, I don't know what that means.
I'm confused by your question. Do you not know what constructors and destructors are?
I've never used them before. Sorry. I am reading up on them right now however.
Um... you have a constructor and destructor defined right there in your code!
I see that now, this is an old package from someone else I am trying to make use-able. I am also not very familiar with classes and structures, before this project I had never used one.
It would seem the constructor/destructor are defined via:

1
2
#ifndef G4LElastic_h
#define G4LElastic_h 1 



Any ideas why it is breaking if the constructor/destructor are defined properly?
Last edited on
That's an include guard.

Maybe it'd be advisable to learn the language before trying to things with it?
OK, appreciate the heads-up. Thanks for the help.
Topic archived. No new replies allowed.