[knc1]

Originally Posted by nasser

knc1,

Here's the entire message dump when trying to run it on PW1:

[root@kindle tw251]# ./taskwarrior.sh 
./task: /lib/libc.so.6: version `GLIBC_2.15' not found (required by tasklib/libgnutls-deb0.so.28)
./task: /lib/libc.so.6: version `GLIBC_2.17' not found (required by tasklib/libgnutls-deb0.so.28)
./task: /lib/libc.so.6: version `GLIBC_2.18' not found (required by tasklib/libstdc++.so.6)
./task: /lib/libc.so.6: version `GLIBC_2.17' not found (required by tasklib/libstdc++.so.6)
./task: /lib/libc.so.6: version `GLIBC_2.16' not found (required by tasklib/libp11-kit.so.0)
./task: /lib/libc.so.6: version `GLIBC_2.15' not found (required by tasklib/libp11-kit.so.0)

Originally Posted by knc1

So use your tools to list the symbols being requested.
Your choice of objdump, readelf, nm (and probably others that slip my mind at the moment).

OK, a worked example:

knc1:tasklib> objdump -T libgnutls-deb0.so.28 | grep -E 'GLIBC_2.15|GLIBC_2.17'
00000000      DF *UND*    00000000  GLIBC_2.17  clock_gettime
00000000      DF *UND*    00000000  GLIBC_2.15  __fdelt_chk

and then something like:

knc1:tasklib> man clock_gettime

And find among other things that the system call was introduced in Kernel-2.6
So the kernel being run is recent enough, only thing needed is the symbol definition.

I.E: A small code file, whose *.o is included in the link command of the build.

Here is an example cribbed from the web for a different symbol (Cliff's notes version):

$ objdump -p myprog
...
Version References:
  required from libc.so.6:
    0x09691972 0x00 05 GLIBC_2.3
    0x09691a75 0x00 03 GLIBC_2.2.5

$ objdump -T myprog | fgrep GLIBC_2.3
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.3   realpath

// Check depended upon library for symbol versions:

$ objdump -T /lib/libc.so.6 | grep -w realpath
0000000000105d90 g    DF .text  0000000000000021 (GLIBC_2.2.5) realpath
000000000003e7b0 g    DF .text  00000000000004bf  GLIBC_2.3   realpath

// Request the earlier symbol version in your application:

#include <limits.h>
#include <stdlib.h>

__asm__(".symver realpath,realpath@GLIBC_2.2.5");

int main () {
    realpath ("foo", "bar");
}

// Check re-compiled application:

$ objdump -p myprog
...
Version References:
  required from libc.so.6:
    0x09691a75 0x00 02 GLIBC_2.2.5

$ objdump -T myprog | grep realpath
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 realpath

Now the above presumed you wanted to change your source code.
But the same could be put into its own source code, compiled to an -FPIC shared *.o.
Now, how to get it included in the build without modifying the source code, or even the build script / makefile (or whatever the application uses).

Look in /usr/lib and you should find a symbolic link from the soname to the file which actually provides the code, as in (only an example from my desktop, not the names you need to look for):

knc1:lib> ls -l | grep libgnu
lrwxrwxrwx  1 root root        20 Jun 28 06:04 libgnutls.so.30 -> libgnutls.so.30.14.5
-rwxr-xr-x  1 root root   1361328 Jun 28 06:04 libgnutls.so.30.14.5

Let's assume your files are clock_gettime.c and clock_gettime.o or *.so
Replace the symbolic link using the soname with a (text) file of the same name and extension.
Your text file needs to contain:

GROUP( clock_gettime.so, libgnutls.so.30.14.5)

Note: I may have typo'd that in some strange and/or wonderful way - I don't have the reference materials in front of me. Just consider it an illustration of the procedure.
Note: the 'GROUP' command also alters the search order of the linker.

Edit: I did.
It is gnutls that is requesting a sysmbol missing from libc.so
So the name of the new provider needs to go in the libc.so group command file.
What I wrote above is as if the application was requesting a symbol missing from libgnutls.
Too tired to fix it tonight, but you should have enough clues now to follow up on a fix for taskwarrior on older systems.

The arguments to the 'GROUP' may be absolute or relative paths to the name of the file(s) that provide the symbols associated with the soname.

Display the contents of your: /usr/lib/libc.so
for a worked/working example (it is a text file with linker commands, not a binary).

= = = =

Note:
Building on a FAT-32 system (which does not support symbolic links) requires a whole lot of these little linker command files to associate the soname with the name of the file providing the binary (without using symbolic links).

I think twobob did it (several times) but I am not sure if even you found his post/files, they would help now - probably too old by now anyway.