Need to manually add ./google/protobuf/.libs/descriptor.pb.o to get protoc to link

[sweetcw]

Link error: undefined reference to 'scc_info_FileDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto'

Using an ARM docker to compile for ARM Yocto environment. Apply patch found here so autogen will work.

bash-4.3# g++ --version g++ (GCC) 4.9.3 bash-4.3# libtool --version libtool (GNU libtool) 2.4.6

Commands: bash-4.3# ./autogen bash-4.3# ./configure bash-4.3# make

Get the following error: /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wno-sign-compare -O2 -g -std=c++11 -DNDEBUG -pthread -o protoc goo gle/protobuf/compiler/main.o libprotobuf.la libprotoc.la -lz libtool: link: g++ -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wno-sign-compare -O2 -g -std=c++11 -DNDEBUG -pthread -o .libs/protoc google/protobuf/compiler/main .o ./.libs/libprotobuf.so ./.libs/libprotoc.so /home/root/protobuf/src/.libs/libprotobuf.so /usr/lib/libstdc++.so -lm -lz -pthread -Wl,-rpath -Wl,/usr/local/lib ./.libs/libprotoc.so: error: undefined reference to 'scc_info_FileDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto' collect2: error: ld returned 1 exit status Makefile:3499: recipe for target 'protoc' failed make[2]: [protoc] Error 1 make[2]: Leaving directory '/home/root/protobuf/src' Makefile:1559: recipe for target 'all-recursive' failed make[1]: [all-recursive] Error 1 make[1]: Leaving directory '/home/root/protobuf' Makefile:1466: recipe for target 'all' failed make: *** [all] Error 2

To resolve I call the following: bash-4.3# cd src bash-4.3# /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall -Wno-sign-compare -O2 -g -std=c++11 -DNDEBUG -pthread -o pro toc google/protobuf/compiler/main.o libprotobuf.la libprotoc.la ./google/protobuf/.libs/descriptor.pb.o -lz

Help avoiding the last manual step so make completes successfully on its own would be appreciated. TIA!

[xfxyjwf]

Try cmake instead? We are considering deprecating/removing the autotools support.

[VNDJ]

I got the same error, and it was solved by run the cmd manually!

[sweetcw]

CMake does build and run without error. It's not obvious cmake is supported for Linux, the instructions only mention Windows. For those that run into this in the future, here are the commands I used for building for Linux:

cd protobuf/cmake mkdir build cd build cmake -DCMAKE_BUILD_TYPE=Release -Dprotobuf_BUILD_TESTS=OFF ../ make -j16

[blueberryCoder]

i got the same error i use ndk for android

[AsteriskZuo]

I have the same problem. protobuf version 3.11.4. Static library compilation is no problem. The dynamic library has been inaccessible.

[journey175]

I got the same question when cross-compile protobuf c++ 3.11.4 for arm-linux, it describe the error : ./.libs/libprotoc.so : error: undefined reference to 'scc_info_FileDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto',

[LourensVeen]

I'm seeing this issue as well on some machines, when building using autotools. It's mentioned at https://github.com/protocolbuffers/protobuf/issues/5107 that this is an issue with the GOLD linker, but I can reproduce it on GNU LD 2.30 (and GCC 7.3.0) as well, although it works fine on another machine also with GNU LD 2.30 and GCC 7.5.0.

It seems that the problem is that the scc_info_* and descriptor_table_* symbols are not extern "C++", and therefore on some linkers do not match the *google* wildcard in the version script. If I modify the src/libprotoc.map, src/libprotobuf.map and src/libprotobuf-lite.map files to read

{
  global:
    extern "C++" {
      *google*;
    };
    scc_info_*;
    descriptor_table_*;

  local:
    *;
};

then it builds correctly using autotools. Possible a broader *google*; pattern outside of the extern "C++" is a better solution in the long run, but this seems to be the minimal match needed on Protobuf 3.10.0 at least.

It looks like building with CMake is not really a fix, https://github.com/protocolbuffers/protobuf/issues/6113 says that there's a bug in the CMake build leading it to not use the version scripts, which hides the problem (because all symbols are now public) but doesn't solve it properly. It may be good to reopen this issue because of this.

[journey175]

@LourensVeen thank you very much ,your reply solved my problem.

[fmartinsons]

Hello there, I had the same issues using python protobuf (so no problem during compilation but undefined reference at runtime) version 3.11.4):

      File "/usr/lib/python3.8/site-packages/sigfox/protobuf/basestationsystem_pb2.py", line 6, in <module>
        from google.protobuf import descriptor as _descriptor
      File "/usr/lib/python3.8/site-packages/google/protobuf/descriptor.py", line 47, in <module>
        from google.protobuf.pyext import _message
    ImportError: /usr/lib/python3.8/site-packages/google/protobuf/pyext/_message.cpython-38-x86_64-linux-gnu.so: undefined symbol: descriptor_table_google_2fprotobuf_2fdescriptor_2eproto

I corrected that thanks to @LourensVeen suggestion but I would like to know the real fix (or at least the merge of the modified *.map). Is somebody has news about this subject ?

[LourensVeen]

I figured I'd try to make a pull request with the map file update, but apparently the real fix was to remove autotools and require Bazel instead (https://github.com/protocolbuffers/protobuf/pull/10132). I don't know if Bazel ignores the map files like CMake does, but if anyone can reproduce this while building with Bazel then I'll try to submit a PR for the map files update anyway. I've removed gRPC/protobuf from my application, so I can't justify doing a bunch of testing with Bazel myself, sorry.

[fmartinsons]

I use yocto build system to cross compile protobuf so I'm dependent on them. Their master branch contains the patch you mention for compiling protobuf, see there

They mention issue #6113 like you did. So it seems the patch on map files would be interesting to be merge,isn't it ?

[LourensVeen]

That got me confused for a bit, since yocto seems to be using CMake to build it, but then I discovered that #6113 has been fixed now, so that CMake now does use the map files and yocto needs to apply the patch to get things to work. Sounds like it's worth a PR then, I'll try to make one.