#1219 Fails to start because of undefined symbol: clock_gettime

Reporter thededem
Owner Nobody
Created
Updated
Stars ★ (1)
Tags
  • Status-Accepted
  • Priority-Medium
  • Type-Defect
  1. thededem on

    When trying to run the latest version from trunk (changeset 8e7feec95e8d), prosody does not start up with the following error: Encountered error: error loading module 'util.time' from file '<prefix>/lib/prosody/util/time.so': <prefix>/lib/prosody/util/time.so: <prefix>/lib/prosody/util/time.so: undefined symbol: clock_gettime Before, I was running code from trunk from July 30 where the error did not appear. I was able to solve the problem by linking librt.so to the shared libs by adding "-lrt" to the linker flags (LDFLAGS) in the configure script (although I do not know, if this is the proper way to fix the issue). System information: CentOS 6.10 gcc 5.2.0

  2. Zash on

    Hi, thanks for the report. The manual for clock_gettime does say > Link with -lrt (only for glibc versions before 2.17). So it seems you figured it out. I don't know what to do next.

    Changes
    • tags Status-Accepted
  3. thededem on

    I guess the configure script should include some check, to see if the glibc version is 2.17 or below and in that case -lrt should be added to the linker flags. Something like GLIBC_VERSION_PART_1=$(ldd --version | head -n1 | cut -d' ' -f4 | cut -d'.' -f1) GLIBC_VERSION_PART_2=$(ldd --version | head -n1 | cut -d' ' -f4 | cut -d'.' -f2) if [ $GLIBC_VERSION_PART_1 -le 2 ] && [ $GLIBC_VERSION_PART_2 -le 17 ] then LDFLAGS="$LDFLAGS -lrt" fi

  4. Zash on

    I wonder if there's any harm in just always linking with -lrt, like: diff -r cc593002f2e2 util-src/GNUmakefile --- a/util-src/GNUmakefile Fri Oct 12 17:28:08 2018 +0200 +++ b/util-src/GNUmakefile Fri Oct 12 17:34:04 2018 +0200 @@ -30,5 +30,7 @@ hashes.so: LDLIBS+=$(OPENSSL_LIBS) crand.o: CFLAGS+=-DWITH_$(RANDOM) crand.so: LDLIBS+=$(RANDOM_LIBS) +time.so: LDLIBS+=-lrt + %.so: %.o $(LD) $(LDFLAGS) -o $@ $^ $(LDLIBS)

  5. thededem on

    It seems, that librt is not present on all os's (eg. not on mac os/os x), so I guess this could lead to problems. (I found this blog post dealing with linking librt: https://flameeyes.blog/2012/12/26/glibc-2-17-what-s-going-to-be-a-trouble/) Given the fact, that glibc 2.17 was released in December 2012, maybe it is sufficient to just document the issue for people with outdated software (like me) and leave the code uncluttered of this legacy stuff.

New comment

Not published. Used for spam prevention and optional update notifications.