libc and undefined symbol: stime

user_1190830 0
Viewed 676

I have an python application that uses the FTDI driver library named:

/usr/local/lib64/libftd2xx.so.1.4.22

When I run the application using libc 2.27, it works fine.

When running it against libc 2.32 it fails with the following:

/usr/local/lib64/libftd2xx.so: undefined symbol: stime

While looking at the libc release, indeed there is something related to stime from libc 2.31 as described at: https://lwn.net/Articles/811315/

It says:

"The obsolete function stime is no longer available to newly linked binaries, and its declaration has been removed from <time.h>."

My understanding from this is that only "new code" cannot compile/link with this function but an existing library that were using this function should still work.

In fact if I look for the stime symbol the rough the below command in both 2.27 and the 2.32 I find that stime is there:

2.27

root@PPL23:~# nm --demangle --dynamic --defined-only --extern-only /lib/x86_64-linux-gnu/libc-2.27.so* | grep stime
00000000000d5ee0 T stime

2.32

localhost /tmp #  nm --demangle --dynamic --defined-only --extern-only /lib64/libc-2.32.so | grep stime
000000000012e490 T stime@GLIBC_2.2.5

Why is libc 2.32 not backward compatible with the existing FTDI driver? Shouldn't that work even with 2.32 version since the symbol seems to be there?

libc glibc
1 Answers

According to the man page stime(2) is deprecated.

NOTE: This function is deprecated; use clock_settime(2) instead.

Instead of:

stime(100)

following code can be used:

clock_settime(CLOCK_REALTIME, (struct timespec*){100,0})

If for some reason you want to go with stime anyway, you may use the assembly trick proposed in the SymbolVersioning

__asm__(".symver stime,stime@GLIBC_2.2.5");
user_116844730
Related