Kevin Kofler via devel wrote:
So now I had a new idea how to figure out what difference the version
of
glibc we are compiling against can make: track down the symbol version:
nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.2 |
grep '(a)GLIBC_2\.33'
U fstat64(a)GLIBC_2.33
U fstatat64(a)GLIBC_2.33
U lstat64(a)GLIBC_2.33
U stat64(a)GLIBC_2.33
So we are getting new symbol versions of the above 4 functions. So now we
only need to know what is different between the above and the syscalls
presumably used previously:
nm -D --with-symbol-versions Downloads/libQt5WebEngineCore.so.5.15.1 |
grep 'stat\(at\)\?64'
U __fxstat64(a)GLIBC_2.2.5
U __fxstatat64(a)GLIBC_2.4
U __lxstat64(a)GLIBC_2.2.5
U __xstat64(a)GLIBC_2.2.5
(That's the version from F33 GA, definitely built against an older glibc.)
PS: This commit:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142...
is why the version of glibc used at compile time makes a difference.
Until glibc 2.32, stat64 etc. were redirected to __xstat64 etc. by inline
functions or macros; glibc 2.33 changed them to true functions. As a result,
code compiled against glibc 2.32 or older will get the old __xstat64 etc.
implementation that is still present, whereas code compiled against glibc
2.33 will get the new stat64 etc. implementation.
Kevin Kofler