[SERVER-11641] undefined symbol: _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE Created: 08/Nov/13  Updated: 10/Dec/14  Resolved: 13/Jan/14

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: Ernie Hershey Assignee: Ernie Hershey
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-11642 undefined symbol on Fedora 8 32-bit w... Closed
Operating System: ALL
Participants:

 Description   

I'm getting this error in Fedora 8 running mongod that was built in centos 6 with gcc 4.8.1.

/data/tmp/mci-push-testing/artifacts/mongod: symbol lookup error: /data/tmp/mci-push-testing/artifacts/mongod: undefined symbol: _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE



 Comments   
Comment by Ernie Hershey [ 11/Nov/13 ]

One last bit of info I also discovered is that Fedora 11, released in June of 2009, is the oldest release of Fedora that will run binaries compiled with that linking feature.

Comment by Ernie Hershey [ 11/Nov/13 ]

Interesting! These posts adds some more context and versioning/timing info about that feature, which was apparently added to g++ 4.5 in August of 2009.

http://stackoverflow.com/questions/11931420/gcc-g-building-without-gnu-unique-object-symbols-for-older-linux-kernels
http://gcc.gnu.org/ml/gcc-help/2013-01/msg00008.html
http://www.redhat.com/archives/posix-c++-wg/2009-August/msg00002.html

Comment by Andrew Morrow (Inactive) [ 11/Nov/13 ]

From the build machine:

# cksum ./mongod
2552015065 17714816 ./mongod
# nm -D ./mongod | grep empty_rep
00000000010e7930 W _ZNSbIwSt11char_traitsIwESaIwEE12_S_empty_repEv
00000000010e84b0 W _ZNSbIwSt11char_traitsIwESaIwEE4_Rep12_S_empty_repEv
0000000001afb700 u _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
00000000010ea440 W _ZNSs12_S_empty_repEv
00000000010eaf80 W _ZNSs4_Rep12_S_empty_repEv
0000000001afb720 u _ZNSs4_Rep20_S_empty_rep_storageE

# cksum ./mongod
2552015065 17714816 ./mongod
# nm -D ./mongod | grep empty_rep
00000000010e7930 W _ZNSbIwSt11char_traitsIwESaIwEE12_S_empty_repEv
00000000010e84b0 W _ZNSbIwSt11char_traitsIwESaIwEE4_Rep12_S_empty_repEv
0000000001afb700 ? _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
00000000010ea440 W _ZNSs12_S_empty_repEv
00000000010eaf80 W _ZNSs4_Rep12_S_empty_repEv
0000000001afb720 ? _ZNSs4_Rep20_S_empty_rep_storageE

Notice that the 'u' fields from the build machines are '?' on the run machine. From 'man nm' on the build machine:

           "u" The symbol is a unique global symbol.  This is a GNU extension to the standard set of ELF symbol bindings.
               For such a symbol the dynamic linker will make sure that in the entire process there is just one symbol
               with this name and type in use.

However, on the run machine the manpage shows that nm is ignorant of this field type.

Looking at 'ld' on each machine:

build:

# ld --version
GNU ld version 2.23.52.0.1-8.el6 20130226

run:

ld --version
GNU ld version 2.17.50.0.18-1 20070731

So the linking environment on the build machine is newer than that on the runtime machine. My read is that the link editor on the build machine is emitting a symbol type that is not understood by the runtime linker on the runtime machine. I'm not aware of a way to step down the target runtime linking environment at link edit time, unfortunately.

Comment by Ernie Hershey [ 11/Nov/13 ]

I just tested in Fedora 9 and got the same error.

Comment by Ernie Hershey [ 10/Nov/13 ]

I do see both of those files there -

[root@ip-10-2-29-40 ~]# ls -l /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 9 2009-11-27 03:15 /lib64/ld-linux-x86-64.so.2 -> ld-2.7.so
[root@ip-10-2-29-40 ~]# ls -l /lib64/libgcc_s.so.1
lrwxrwxrwx 1 root root 28 2009-11-27 03:15 /lib64/libgcc_s.so.1 -> libgcc_s-4.1.2-20070925.so.1
[root@ip-10-2-29-40 ~]# 

Comment by Andrew Morrow (Inactive) [ 09/Nov/13 ]

Does /lib64/ld-linux-x86-64.so.2 exist on the machine where you are trying to run and failing? How about /lib64/libgcc_s.so.1

Comment by Ernie Hershey [ 09/Nov/13 ]

Could it be linked in some incompatible way? On the building system ldd shows healthy output for the same binary -

        linux-vdso.so.1 =>  (0x00007ffffa3ff000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4ce6d75000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f4ce6b6c000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f4ce68e8000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4ce66d2000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4ce633e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4ce6f9c000)

Comment by Andrew Morrow (Inactive) [ 08/Nov/13 ]

We should be dynamically linked to libc, at least.

Comment by Ernie Hershey [ 08/Nov/13 ]

It returns "not a dynamic executable"

Comment by Andrew Morrow (Inactive) [ 08/Nov/13 ]

what does 'ldd /data/tmp/mci-push-testing/artifacts/mongod' say on that machine?

Generated at Thu Feb 08 03:26:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.