Antlr4: GCC undefined reference to `non-virtual thunk to antlr4::Lexer::getSourceName[abi:cxx11]()'

Created on 4 May 2018  路  2Comments  路  Source: antlr/antlr4

This appears to be related to #1601.
That issue was fixed and went into version 4.7
I'm running version 4.7.1 with GCC 7.3.0 and seeing the same problem.

The example reproducing the problem is here https://github.com/ThetaSinner/echelon-unicode-parser at commit 8.

You can see the details of my environment in /env/Dockerfile of that repository.

I'm sure that my linker is configured correctly.

  • GCC's ld is able to find the library
  • If I remove the link to the antlr library then I get hundreds of linker errors - so it really is trying to link

Most helpful comment

I think this comes from the fact that you are compiling the antlr runtime with a different version of g++ than the application you are trying to link it with.

The reason this may happen is because cmake is looking for g++ in your system installation (e.g. /usr/bin/c++) rather than trying to run it from the PATH.

If you build your application (the one that tries to link with antlr4-runtime) with a standard Makefile, it may by default just try to call g++, and therefore take the first one it finds in the PATH.

In my case, it happened because my PATH was pointing to the bin folder of GNAT, which contain it's own version of g++ (more recent that the one from Debian).

So, just in case, try:

export CXX=$(which g++) 

and then call cmake and make.

All 2 comments

I had a similar error message:

CMakeFiles/antlr4-tutorial.dir/antlr4-runtime/CPP14Lexer.cpp.o:(.rodata._ZTV10CPP14Lexer[_ZTV10CPP14Lexer]+0x210): undefined reference to `non-virtual thunk to antlr4::Lexer::getSourceName()'
collect2: error: ld returned 1 exit status

In my case, it disappeared after updating gcc to 7.3.0 and removing the build directory to avoid caching issues:

First, I updated gcc according to this guide http://tuxamito.com/wiki/index.php/Installing_newer_GCC_versions_in_Ubuntu

Second, I ran these commands

rm -rf build/
mkdir build && cd build
cmake ../ && make

I think this comes from the fact that you are compiling the antlr runtime with a different version of g++ than the application you are trying to link it with.

The reason this may happen is because cmake is looking for g++ in your system installation (e.g. /usr/bin/c++) rather than trying to run it from the PATH.

If you build your application (the one that tries to link with antlr4-runtime) with a standard Makefile, it may by default just try to call g++, and therefore take the first one it finds in the PATH.

In my case, it happened because my PATH was pointing to the bin folder of GNAT, which contain it's own version of g++ (more recent that the one from Debian).

So, just in case, try:

export CXX=$(which g++) 

and then call cmake and make.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dzavodnikov picture dzavodnikov  路  5Comments

tzmfreedom picture tzmfreedom  路  8Comments

kaba2 picture kaba2  路  6Comments

james-q-arnold picture james-q-arnold  路  6Comments

prashast picture prashast  路  7Comments