gcc 4.6.3 is about 10 years old, so has no support for c++17 or C++20, which
may the issue here. A quick perusal of the Protobuf web site doesn't mention what C++ standard they program to, nor could I find a newsgroup/forum for users. I did find this google group where you may be able to ask your question:
Protocol Buffers - Google Groups[
^]
I'd really recommend updating your linux distro, if at all possible to something a little more current, like Ubuntu, Debian, Fedora, Mint, etc, which will include a more recent compiler. Debian 12, for example ships with GCC-12.2. If you're stuck with your current linux distro, you should still be able to compile a newer gcc version. I've successfully compiled gcc-12 on CentOS-6, which ships with gcc-4.4.7. Read the instructions on the GNU gcc web site :
Installing GCC- GNU Project[
^] Pay particular attention to the prerequisites: gmp, mpr and mpfr. The default installation location is /usr/local/bin, but you'll need root access to install there. If you do go that root, I highly recommend you use the
--program-suffix= option when configuring, so you can distinguish between the distro provided compiler (gcc/g++) and the newer version (gcc-12/g++-12 e.g. with --program-suffix=-12). Be also aware that the newer g++ compiler provides a newer version of libstc++.
Assuming you install in the default location (/usr/local/lib), then you'll also need to do one of the following
* add /usr/local/lib and /usr/local/lib64 to /etc/ld.so.conf, and then run ldconfig (as root). If you do this, then any older programs will also dynamically link to /usr/local/lib versions of libstdc++, and other libs generated by compiling a new version of C++. As far as I'm aware, that's not a problem, but it might be the source of unexpected results in old C++ programs.
* compile with --static-libstdc++. This makes your executables larger, but you won't get undefined symbol references when you try to run your program
* use LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64 myapp: This adds /usr/local/lib and /usr/local/lib64 to the library loader path
before the standard library path, so myapp will find the newer versions first. You can add
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64 to your .profile so that you don't have to remember to do it every time.
Also, note that Debian derived systems use a somewhat different path for their dynamic libraries, notably /lib/i386-linux-gnu and /lib/x86_64-linux/gnu, so you you should check with your distro where to find them. That's easily done by writing a quick "Hello World" c++ program, and then using ldd to show you where the files are:
k5054@ubuntu$ ldd hello
linux-vdso.so.1 (0x00007ffce12e1000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f88197f4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88195cc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f88194e5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8819a2f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f88194c5000)
k5054@ubuntu$
Finally, if you do install a new version of your compiler, also consider updating binutils and maybe gdb to newer versions too. If you use gdb then note that newer gnu compilers produce dwarf-5 (I think) debug information by default, but older versions of gdb do not know how to deal with it. There are compiler switches to produce older dwarf-3 or dwarf-4 debug info, but it can be annoying to have to remember to either configure your build to use them.
Submit an article or tip