Quote:
Originally Posted by nasser
Thanks, knc1!
While I was trying out, you already posted an example!
My output:
Code:
$ readelf -s libgnutls-deb0.so.28|grep GLIBC_2.1
51: 00000000 0 FUNC GLOBAL DEFAULT UND clock_gettime@GLIBC_2.17 (13)
91: 00000000 0 FUNC GLOBAL DEFAULT UND __fdelt_chk@GLIBC_2.15 (14)
$ readelf -s libstdc++.so.6|grep GLIBC_2.1
16: 00000000 0 FUNC GLOBAL DEFAULT UND clock_gettime@GLIBC_2.17 (38)
70: 00000000 0 FUNC GLOBAL DEFAULT UND __cxa_thread_atexit_impl@GLIBC_2.18 (40)
$ readelf -s libp11-kit.so.0|grep GLIBC_2.1
71: 00000000 0 FUNC GLOBAL DEFAULT UND getauxval@GLIBC_2.16 (6)
$ objdump -T libgnutls-deb0.so.28|grep GLIBC_2.1
00000000 DF *UND* 00000000 GLIBC_2.17 clock_gettime
00000000 DF *UND* 00000000 GLIBC_2.15 __fdelt_chk
$ objdump -T libstdc++.so.6|grep GLIBC_2.1
00000000 DF *UND* 00000000 GLIBC_2.17 clock_gettime
00000000 DF *UND* 00000000 GLIBC_2.18 __cxa_thread_atexit_impl
$ objdump -T libp11-kit.so.0|grep GLIBC_2.1
00000000 DF *UND* 00000000 GLIBC_2.16 getauxval
So, the functions being requested are:
Code:
GLIBC_2.15: __fdelt_chk
GLIBC_2.16: getauxval
GLIBC_2.17: clock_gettime
GLIBC_2.18: __cxa_thread_atexit_impl
Actually, libp11-kit.so.0 should also be needing GLIBC_2.15, as per the runtime error messages, but in the above, it shows that only GLIBC_2.16 is being requested. Don't know why this difference. 
Now, I'll try to check further as indicated by you...  |
I wrote most of the above from memory at the end of a long and tiring day.
The general, overall concept(s) should be correct, all of the details may be wrong or incorrectly described.
What I had intended to do was extract (and compiled as individual libraries) the changes from one system library version to the next.
Then do a sequence of individual, partial, linking steps. Those steps would have statically linked in ONLY the 'shim' code.
In your case, only 4 library functions (out of the zillion or more that would still be dynamically linked in at runtime).
In my example that I was working on, before SuseStudio went belly-up last week, was memcpy. (The support and maintenance of which has fallen into a black hole during the MicroFocus purchase of Novell (who owns (owned) Suse).
In that case, the way to get applications to link that require memcpy-GLIBC_2.14 or more recent is to write a one line source file that provides a function called mempy that is versioned as GLIBC_2.14 that in fact call memmov with the same arguments it was passed and returns the result returned by memmov.
(In fact, that is what memcpy_2.14 does, calls memmov).
I don't know what the 'backport action' is required for your four symbols.
But that only means I haven't looked (yet).
One thing that puzzles me is:
Symbols that begin with "_" are suppose to be "private" and symbols that begin with "__" are suppose to be "protected".
The 'C' language does not implement those classifications, but they are suppose to be implemented by agreed upon practice.
So I am surprised to see GNU tls (thread local storage) calling any "__" symbol of GNU libc (the system library).
But the folks at GNU development wrote them both and also wrote the 'rules' of how symbols that begin with one or more underscores are intended to be used.
So I guess they can get away with doing whatever they please.
= = = = =
And none of the above deals with symbols missing from libraries that are DLopened.
Which is probably where your error at run time but not at load time is coming from.
To find those, it will probably be required to 'instrument' the DL** (dynamic load) set of library entries.
The GNU toolchain has the ability to instrument any symbol reference. Known as a "wrap" function, passed to the linker from the compiler command line as -Wl,wrap .... option.
And in fact, it tells the linker to add a double pair of underscores to the external symbol name.
Which only deepens the mystery in my mind described above about symbol naming in actual practice.
But then I am old and easily befuddled.