* Question regarding __clock_gettime symbol visibility across glibc build
@ 2020-03-17 7:47 Lukasz Majewski
2020-03-17 8:34 ` Florian Weimer
2020-03-21 7:00 ` Lukasz Majewski
0 siblings, 2 replies; 6+ messages in thread
From: Lukasz Majewski @ 2020-03-17 7:47 UTC (permalink / raw)
To: libc-help; +Cc: Joseph Myers, Florian Weimer
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding __clock_gettime symbol visibility across glibc build
2020-03-17 7:47 Question regarding __clock_gettime symbol visibility across glibc build Lukasz Majewski
@ 2020-03-17 8:34 ` Florian Weimer
2020-03-17 8:51 ` Lukasz Majewski
2020-03-21 7:00 ` Lukasz Majewski
1 sibling, 1 reply; 6+ messages in thread
From: Florian Weimer @ 2020-03-17 8:34 UTC (permalink / raw)
To: Lukasz Majewski; +Cc: libc-help, Joseph Myers
* Lukasz Majewski:
> 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.
All exported glibc symbols are versioned. Chances are that nm does
not look at the dynamic symbol table at all, so its output is
misleading. I usually use eu-readelf --symbols=.dynsym instead.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding __clock_gettime symbol visibility across glibc build
2020-03-17 8:34 ` Florian Weimer
@ 2020-03-17 8:51 ` Lukasz Majewski
0 siblings, 0 replies; 6+ messages in thread
From: Lukasz Majewski @ 2020-03-17 8:51 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-help, Joseph Myers
[-- Attachment #1: Type: text/plain, Size: 3133 bytes --]
Hi Florian,
> * Lukasz Majewski:
>
> > 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.
> >
>
> All exported glibc symbols are versioned. Chances are that nm does
> not look at the dynamic symbol table at all, so its output is
> misleading. I usually use eu-readelf --symbols=.dynsym instead.
It seems like nm is correct here.
The output of installed libc.so:
root@y2038arm:/opt# readelf --symbols /opt/lib/libc.so.6 | grep clock_gettime
846: 000702bd 64 FUNC GLOBAL DEFAULT 12 __clock_gettime@@GLIBC_PRIVATE
1515: 00070265 88 FUNC GLOBAL DEFAULT 12 __clock_gettime64@@GLIBC_PRIVATE
1751: 000702bd 64 FUNC GLOBAL DEFAULT 12 clock_gettime@GLIBC_2.4
1755: 000702bd 64 FUNC GLOBAL DEFAULT 12 clock_gettime@@GLIBC_2.17
3830: 00000000 0 FILE LOCAL DEFAULT ABS clock_gettime.c
10342: 000702bd 64 FUNC LOCAL DEFAULT 12 __clock_gettime_2
10624: 00070265 88 FUNC LOCAL DEFAULT 12 __GI___clock_gettime64
11251: 000702bd 64 FUNC LOCAL DEFAULT 12 __GI___clock_gettime
11893: 000702bd 64 FUNC GLOBAL DEFAULT 12 __clock_gettime
11966: 000702bd 64 FUNC GLOBAL DEFAULT 12 clock_gettime@GLIBC_2.4
12166: 00070265 88 FUNC GLOBAL DEFAULT 12 __clock_gettime64
13749: 000702bd 64 FUNC GLOBAL DEFAULT 12 clock_gettime@@GLIBC_2.17
The one when libmemusage.so is linked:
readelf --symbols glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc.so | grep clock_gettime
834: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 __clock_gettime@@GLIBC_PRIVATE
1729: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 clock_gettime@GLIBC_2.4
1733: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 clock_gettime@@GLIBC_2.17
3658: 00000000 0 FILE LOCAL DEFAULT ABS clock_gettime.c
9435: 0009a774 364 FUNC LOCAL DEFAULT 11 __clock_gettime64
10187: 0009a8e0 100 FUNC LOCAL DEFAULT 11 __clock_gettime_2
10478: 0009a774 364 FUNC LOCAL DEFAULT 11 __GI___clock_gettime64
11124: 0009a8e0 100 FUNC LOCAL DEFAULT 11 __GI___clock_gettime
11729: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 __clock_gettime
11802: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 clock_gettime@GLIBC_2.4
13564: 0009a8e0 100 FUNC GLOBAL DEFAULT 11 clock_gettime@@GLIBC_2.17
The results are the same -> __clock_gettime64 is GLOBAL on installed glibc
and LOCAL when linking libmemusage.so.
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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding __clock_gettime symbol visibility across glibc build
2020-03-17 7:47 Question regarding __clock_gettime symbol visibility across glibc build Lukasz Majewski
2020-03-17 8:34 ` Florian Weimer
@ 2020-03-21 7:00 ` Lukasz Majewski
2020-03-23 21:57 ` Joseph Myers
1 sibling, 1 reply; 6+ messages in thread
From: Lukasz Majewski @ 2020-03-21 7:00 UTC (permalink / raw)
To: libc-help; +Cc: Joseph Myers, Florian Weimer, Adhemerval Zanella
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding __clock_gettime symbol visibility across glibc build
2020-03-21 7:00 ` Lukasz Majewski
@ 2020-03-23 21:57 ` Joseph Myers
2020-03-23 22:14 ` Lukasz Majewski
0 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2020-03-23 21:57 UTC (permalink / raw)
To: Lukasz Majewski; +Cc: libc-help, Florian Weimer, Adhemerval Zanella
On Sat, 21 Mar 2020, Lukasz Majewski wrote:
> > /work/lukma/glibc/glibc-many-build/src/glibc/malloc/memusage.c:181:
> > undefined reference to `__clock_gettime64'
I.e. __clock_gettime64 is not exported at any symbol version in the
dynamic symbol table of libc.so.
Any symbol defined in libc.so and used in another glibc shared library or
executable needs to be exported at some symbol version in some Versions
file. In the case of symbols for 64-bit time, it should be exported at
version GLIBC_PRIVATE until we're ready to support _TIME_BITS=64 in the
headers, at which point all such symbols should be exported at the version
of the next glibc release and be removed from GLIBC_PRIVATE if there.
> > nm
> > ./work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc.so
> > | grep clock_gettime
nm uses the static symbol table by default. You need nm -D, objdump -T
(shows symbol versions as well) or readelf --dyn-syms to look at the
dynamic symbol table.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question regarding __clock_gettime symbol visibility across glibc build
2020-03-23 21:57 ` Joseph Myers
@ 2020-03-23 22:14 ` Lukasz Majewski
0 siblings, 0 replies; 6+ messages in thread
From: Lukasz Majewski @ 2020-03-23 22:14 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-help, Florian Weimer, Adhemerval Zanella
[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]
Hi Joseph,
> On Sat, 21 Mar 2020, Lukasz Majewski wrote:
>
> > > /work/lukma/glibc/glibc-many-build/src/glibc/malloc/memusage.c:181:
> > > undefined reference to `__clock_gettime64'
>
> I.e. __clock_gettime64 is not exported at any symbol version in the
> dynamic symbol table of libc.so.
>
> Any symbol defined in libc.so and used in another glibc shared
> library or executable needs to be exported at some symbol version in
> some Versions file. In the case of symbols for 64-bit time, it
> should be exported at version GLIBC_PRIVATE until we're ready to
> support _TIME_BITS=64 in the headers, at which point all such symbols
> should be exported at the version of the next glibc release and be
> removed from GLIBC_PRIVATE if there.
And the penny has dropped. The __clock_gettime64 indeed is not exported
in the current glibc. It is exported with my patches for Y2038 support.
I will export __clock_gettime64 in this patch series. Big thanks for the
explanation.
>
> > > nm
> > > ./work/glibc/glibc-many-build/build/glibcs/arm-linux-gnueabi/glibc/libc.so
> > > | grep clock_gettime
>
> nm uses the static symbol table by default. You need nm -D, objdump
> -T (shows symbol versions as well) or readelf --dyn-syms to look at
> the dynamic symbol table.
>
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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-23 22:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-17 7:47 Question regarding __clock_gettime symbol visibility across glibc build Lukasz Majewski
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
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).