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.

# ** 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:

$ /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:

$ 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

$ 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

$ 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.

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

Hope the process help you to figure out and solve your GLIBC problem. Have fun.



How to solve the GLIBC versoin not found issue

Please tell us what's in your mind ...

%d bloggers like this: