#1219 Fails to start because of undefined symbol: clock_gettime
Reporter
thededem
Owner
Zash
Created
Updated
Stars
★ (1)
Tags
Status-Fixed
Priority-Medium
Type-Defect
Component-Docs
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
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
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
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)
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.
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
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.
ChangesI 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
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)
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.
Documented on https://prosody.im/doc/packagers in https://hg.prosody.im/site/rev/95e1d70aa3cd I'm told that the Red Hat package maintainer has taken care of this in their Prosody packages. Thanks again for the report.
Changes