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.
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.
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:
and then call cmake and make.