From: Lukasz Majewski <lukma@denx.de>
To: libc-help@sourceware.org
Cc: Joseph Myers <joseph@codesourcery.com>,
Florian Weimer <fweimer@redhat.com>
Subject: Question regarding __clock_gettime symbol visibility across glibc build
Date: Tue, 17 Mar 2020 08:47:24 +0100 [thread overview]
Message-ID: <20200317084724.6df11fb1@jawa> (raw)
[-- Attachment #1: Type: text/plain, Size: 6413 bytes --]
Dear community,
I'm trying to replace all the occurences of __clock_gettime with
__clock_gettime64 to avoid time bugs on archs with __WORDSIZE == 32 &&
__TIMESIZE != 64 (for now I've omitted the conversion of ntpl,
pthreads,sunrpc)
I've modified: sysdeps/generic/memusage.h (the GETTIME preprocessor
macro).
Unfortunately, several glibc builds fail:
arm-glibc-linux-gnueabi-gcc -shared -static-libgcc -Wl,-O1
-Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux.so.3
-B/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/csu/
-Wl,-soname=libmemusage.so -Wl,-z,combreloc -Wl,-z,relro
-Wl,--hash-style =both
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/math
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/elf
-L/home/lukma/work/
glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/dlfcn
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nss
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nis
-L/home/lukma/work/glibc/glibc-many-build
/build/glibcs/arm-linux-gnueabi/glibc/rt
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/resolv
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/mathvec
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-
linux-gnueabi/glibc/support
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/crypt
-L/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nptl
-Wl,-rpath-link=/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-lin
ux-gnueabi/glibc:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/math:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/elf:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/dlfcn:/home/lukm
a/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nss:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nis:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/rt:/home/lukma/work/glibc/glibc-many-build/b
uild/glibcs/arm-linux-gnueabi/glibc/resolv:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/mathvec:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/support:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-lin
ux-gnueabi/glibc/crypt:/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/nptl
-o
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage.so
-T /home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-
gnueabi/glibc/shlib.lds
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/csu/abi-note.o
-Wl,--whole-archive
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage_pic.a
-Wl,--no-whole-archive /home/lukma/
work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/dlfcn/libdl.so.2
-Wl,--start-group
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc.so
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc_nons
hared.a -Wl,--as-needed
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/elf/ld.so
-Wl,--no-as-needed -Wl,--end-group
/work/lukma/glibc/glibc-many-build/install/compilers/arm-linux-gnueabi/bin/../lib/gcc/arm-glibc-linux-gnueabi/9.2.1/../../../../arm-glibc-linux-gnueabi/bin/ld:
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage_pic.a(memusage.os
): in function `update_data':
/work/lukma/glibc/glibc-many-build/src/glibc/malloc/memusage.c:181:
undefined reference to `__clock_gettime64'
/work/lukma/glibc/glibc-many-build/install/compilers/arm-linux-gnueabi/bin/../lib/gcc/arm-glibc-linux-gnueabi/9.2.1/../../../../arm-glibc-linux-gnueabi/bin/ld:
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage_pic.a(memusage.os
): in function `me':
/work/lukma/glibc/glibc-many-build/src/glibc/malloc/memusage.c:271:
undefined reference to `__clock_gettime64'
/work/lukma/glibc/glibc-many-build/install/compilers/arm-linux-gnueabi/bin/../lib/gcc/arm-glibc-linux-gnueabi/9.2.1/../../../../arm-glibc-linux-gnueabi/bin/ld:
/home/lukma/work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/malloc/libmemusage_pic.a(memusage.os
): in function `dest':
/work/lukma/glibc/glibc-many-build/src/glibc/malloc/memusage.c:822:
undefined reference to `__clock_gettime64' collect2: error: ld returned
1 exit status
This is what I see from the local build directory:
nm
./work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc.so
| grep clock_gettime
0009a8e0 T __clock_gettime
0009a8e0 t __clock_gettime_2
0009a774 t __clock_gettime64
0009a8e0 T clock_gettime@@GLIBC_2.17
0009a8e0 T clock_gettime@GLIBC_2.4
0009a8e0 t __GI___clock_gettime
0009a774 t __GI___clock_gettime64
Apparently the __clock_gettime64 is a local symbol in the libc.so.
However, I've checked how it looks on the installed glibc:
root@y2038arm:/opt# nm /opt/lib/libc.so.6 | grep clock_gettime
000702bc t __GI___clock_gettime
00070264 t __GI___clock_gettime64
000702bc T __clock_gettime
00070264 T __clock_gettime64
000702bc t __clock_gettime_2
000702bc T clock_gettime@@GLIBC_2.17
000702bc T clock_gettime@GLIBC_2.4
In the installed glibc the __clock_gettime64 is an external symbol.
Why the symbol (__clock_gettime64) is local when I try to link
malloc/libmemusage.so and then it becomes global when glibc is
installed?
In other parts of the glibc - for example
sysdeps/unix/sysv/linux/clock.c I can use __clock_gettime64 without any
issues.
Is such behavior related to strong_allias() declaration (as for example
in __clock_settime for which we do have similar situation)?
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2020-03-17 7:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 7:47 Lukasz Majewski [this message]
2020-03-17 8:34 ` Florian Weimer
2020-03-17 8:51 ` Lukasz Majewski
2020-03-21 7:00 ` Lukasz Majewski
2020-03-23 21:57 ` Joseph Myers
2020-03-23 22:14 ` Lukasz Majewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200317084724.6df11fb1@jawa \
--to=lukma@denx.de \
--cc=fweimer@redhat.com \
--cc=joseph@codesourcery.com \
--cc=libc-help@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).