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 #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, #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.