From: Lukasz Majewski <lukma@denx.de>
To: libc-help@sourceware.org
Cc: Joseph Myers <joseph@codesourcery.com>,
Florian Weimer <fweimer@redhat.com>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>
Subject: Re: Question regarding __clock_gettime symbol visibility across glibc build
Date: Sat, 21 Mar 2020 08:00:40 +0100 [thread overview]
Message-ID: <20200321080040.7ac91d19@jawa> (raw)
In-Reply-To: <20200317084724.6df11fb1@jawa>
[-- Attachment #1: Type: text/plain, Size: 7091 bytes --]
On Tue, 17 Mar 2020 08:47:24 +0100
Lukasz Majewski <lukma@denx.de> wrote:
> 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)?
>
>
Does anybody have any input on the described above problem?
Thanks in advance.
>
> 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
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 prev parent reply other threads:[~2020-03-21 7:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 7:47 Lukasz Majewski
2020-03-17 8:34 ` Florian Weimer
2020-03-17 8:51 ` Lukasz Majewski
2020-03-21 7:00 ` Lukasz Majewski [this message]
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=20200321080040.7ac91d19@jawa \
--to=lukma@denx.de \
--cc=adhemerval.zanella@linaro.org \
--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).