[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: |
|
||||||||
| 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 | |||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 11/Nov/13 ] | |||||||||||||||||||||||||
|
From the build machine:
Notice that the 'u' fields from the build machines are '?' on the run machine. From 'man nm' on the build machine:
However, on the run machine the manpage shows that nm is ignorant of this field type. Looking at 'ld' on each machine: build:
run:
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 -
| |||||||||||||||||||||||||
| 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 -
| |||||||||||||||||||||||||
| 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? |