Liaison avec une ancienne version de libc pour offrir une plus grande couverture d'applications

Question

Les binaires Linux sont généralement liée de façon dynamique au cœur du système, de la bibliothèque (libc). Ceci permet de conserver l'empreinte mémoire du binaire assez faible, mais les binaires qui sont tributaires de la dernière version des bibliothèques ne va pas s'exécuter sur des systèmes plus anciens. A l'inverse, les binaires liés à d'anciennes bibliothèques de courir joyeusement sur les systèmes les plus récents.

Par conséquent, afin d'assurer notre application dispose d'une bonne couverture au cours de la distribution, nous avons besoin de comprendre le plus ancien de la libc, nous pouvons soutenir et le lien entre nos binaire contre.

Quelqu'un aurait-il des conseils et/ou des connaissances sur la façon de déterminer la version la plus ancienne de la libc nous pouvons lier?

Merci - Gearoid

Answer 1

Travailler sur les symboles dans votre exécutable de la création de la dépendance sur les indésirables de la version de la glibc.

$ 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

Regarder à l'intérieur de la dépendait-à la bibliothèque pour voir s'il y a des symboles dans les anciennes versions que vous pouvez lier à l'encontre de:

$ 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

Nous sommes de la chance!

Demande la version de GLIBC_2.2.5 dans votre code:

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

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

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

Observer que GLIBC_2.3 est plus nécessaire:

$ 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

Pour de plus amples informations, voir http://www.trevorpounds.com/blog/?p=103.

Answer 2

Malheureusement, dans ma situation, @Sam méthode n'aide pas. Mais, selon lui, j'ai trouvé ma propre façon de résoudre cela.

C'est ma situation:

Je suis en train d'écrire un thrift programme de serveur à l'aide de C++. - Je lier mon programme avec libthrift.un pour le rendre exécutable sur d'autres machines sans libthrift.donc installée. Cependant, mon système a une glibc avec la version 2.15, qui fournit memcpy@GLIBC_2.14 à mon programme alors que notre serveur de machine a seulement la glibc depuis la version 2.5 qui ont seulement memcpy@GLIBC_2.2.5. Alors, bien sûr, mon serveur programme ne peut pas fonctionner sur cette machine.

Et voici mon solusion:

1. À l'aide de .symver pour obtenir la ref de memcpy@GLIBC_2.2.5.

2. Écrire myown __envelopper_fonction memcpy qui vient d'appels memcpy@GLIBC_2.2.5 directement.

3. Lorsque le lien de mon programme, ajoutez -Wl,--wrap=memcpy option de gcc/g++.

Le code memtioned en 1 et 2 est ici: https://gist.github.com/nicky-zs/7541169

Answer 3

La glibc 2.2 est une version minimale commune. Cependant, trouver une plate-forme de construction pour cette version peut ne pas être trivial.

Il est probablement préférable de penser au système d’exploitation le plus ancien que vous souhaitez prendre en charge et d’en tirer parti.