I was running into this GLIBC version issue when setting up RTL simulation with DPI call in Questa Sim (Modelsim). Here is the error message from Questa transcript.
|
1 2 |
# ** Error: (vsim-3197) Load of "libtest_hwa.so" failed: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by libtest_hwa.so). # ** Error: (vsim-3748) Failed to load DPI object file "libtest_hwa.so" while trying to resolve 'mcu_main_dpi'. |
After some investigation, it turned out that the RTL simulation server (CentOS 6.8) has an older version of Glibc than the computer I compile the C code (Ubuntu 14.04). Due to one function call: memcpy.
Here are the steps I took to diagnosis and solve the issue.
Step 1: Figure out the glibc version used in the system
There are many ways to find this information. Here I listed two of them and the log on my server was as below.
Method 1:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
$ /lib64/libc.so.6 GNU C Library stable release version 2.12, by Roland McGrath et al. Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-17). Compiled on a Linux 2.6.32 system on 2016-05-10. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. |
Method 2:
|
1 2 3 4 5 6 |
$ ldd --version ldd (GNU libc) 2.12 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. |
The server has glibc version 2.12. So any function that require GLIBC_2.14 won’t be able to run.
Step 2: Find out which function is causing the problem
Method 1: use readelf
|
1 2 3 4 5 |
$ readelf -a libtest_hwa.so | grep GLIBC_2.14 123: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@GLIBC_2.14 (14) 825: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@@GLIBC_2.14 078: 5 (GLIBC_2.2.5) 6 (GLIBCXX_3.4.9) 3 (GLIBCXX_3.4) e (GLIBC_2.14) 0x00c0: Name: GLIBC_2.14 Flags: none Version: 14 |
Method 2: use objdump
|
1 2 3 |
$ objdump -x libtest_hwa.so | grep GLIBC_2.14 0x06969194 0x00 14 GLIBC_2.14 0000000000000000 F *UND* 0000000000000000 memcpy@@GLIBC_2.14 |
It is clear that the memcpy is causing the problem. Actually, it turned out to be a known problem for a long time and I am just the last one to know about it.
Step 3: Fix the problem
Once we figure out what is causing the issue. The fix is relatively easy and many posts have given a simple solution. Just add the following line into the C code will force to pick up the memcpy from an older version of GLIBC.
|
1 |
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5"); |
Hope the process help you to figure out and solve your GLIBC problem. Have fun.
Thanks a lot, Its really helped me a lot.