Mehrere glibc-Bibliotheken auf einem einzelnen host

https://stackoverflow.com/questions/847179

21-08-2019
|

Frage

Mein linux (SLES-8) server hat derzeit glibc-2.2.5-235, aber ich habe ein Programm das wird nicht funktionieren, auf diese version und benötigt glibc-2.3.3.

Ist es möglich, mehrere glibcs installiert auf dem gleichen host?

Dies ist der Fehler, den ich bekomme, wenn ich mein Programm auf dem alten glibc:

./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./myapp)
./myapp: /lib/i686/libpthread.so.0: version `GLIBC_2.3.2' not found (required by ./myapp)
./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./libxerces-c.so.27)
./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by ./libstdc++.so.6)
./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./libstdc++.so.6)

So habe ich eine erstellt ein neues Verzeichnis namens newglibc und kopiert die folgenden Dateien:

libpthread.so.0
libm.so.6
libc.so.6
ld-2.3.3.so
ld-linux.so.2 -> ld-2.3.3.so

und

export LD_LIBRARY_PATH=newglibc:$LD_LIBRARY_PATH

Aber ich bekomme eine Fehlermeldung:

./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libpthread.so.0)
./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by libstdc++.so.6)
./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libm.so.6)
./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by ./newglibc/libc.so.6)
./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libc.so.6)

So scheint es, dass Sie noch die Verlinkung von /lib und nicht abholen, von wo ich Sie?

Vielen Dank

Lösung

Es ist sehr möglich, mehrere Versionen von glibc, die auf dem gleichen system (wir machen das jeden Tag).

Jedoch, Sie müssen wissen, dass glibc besteht aus viele Stücke (200+ shared libraries), die alle übereinstimmen müssen.Eines der Stücke ist ld-linux.so.2 muss match-libc.so.6, oder sehen Sie die Fehler, die Sie sehen.

Der absolute Pfad zu ld-linux.so.2 ist hart codiert in die ausführbare Datei zur link-Zeit, und kann nicht leicht geändert werden, nachdem die link ist getan.

Zu bauen eine ausführbare Datei, die die Arbeit mit der neuen glibc, dies zu tun:

g++ main.o -o myapp ... \
   -Wl,--rpath=/path/to/newglibc \
   -Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2

Die -rpath linker-option wird die runtime-loader Suche nach Bibliotheken /path/to/newglibc (so Sie würde nicht haben zu set LD_LIBRARY_PATH vor dem ausführen), und der -dynamic-linker wird die option "Backen" Pfad korrigieren ld-linux.so.2 in die Anwendung.

Wenn Sie nicht verknüpfen die myapp Anwendung (z.B.weil es ist eine Drittanbieter-binary), alles ist nicht verloren, aber es wird schwieriger.Eine Lösung ist, um eine korrekte chroot Umwelt für es.Eine andere Möglichkeit ist die Verwendung rtldi und eine Binär-editor.

Andere Tipps

Diese Frage ist alt, die anderen Antworten sind alt."Beschäftigt Russisch"s Antwort ist sehr gut und informativ, aber es funktioniert nur, wenn Sie den Quellcode haben.Wenn Sie nicht, die alternativen damals waren sehr schwierig.Glücklicherweise heute haben wir eine einfache Lösung für dieses problem (wie kommentiert in einer seiner Antworten), mit patchelf.Alle Sie haben zu tun ist:

$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp

Und nach, dass, können Sie einfach führen Sie Ihre Datei:

$ ./myapp

Keine Notwendigkeit zu chroot oder manuell Bearbeiten Binärdateien, zum Glück.Aber denken Sie daran, ein backup Ihrer binary patchen, bevor Sie es, wenn Sie nicht sicher sind, was Sie tun, denn es ändert Ihre Binär-Datei.Nachdem Sie die patch, kann man nicht wieder die alten Pfad zum interpreter/rpath.Wenn es nicht funktioniert, müssen Sie zu halten, patchen, bis Sie den Weg finden, der tatsächlich die Arbeit...Nun, es wird nicht werden müssen eine trial-and-error-Prozess.Zum Beispiel im OP-Beispiel, die er benötigt GLIBC_2.3,, so dass Sie leicht finden können, die lib bietet diese version mit strings:

$ strings /lib/i686/libc.so.6 | grep GLIBC_2.3
$ strings /path/to/newglib/libc.so.6 | grep GLIBC_2.3

In der Theorie, den ersten grep kommen würde leer, da das system libc nicht die version, die er will, und 2. sollte man die Ausgabe GLIBC_2.3, weil es die version myapp ist, verwenden, so dass wir wissen, wir können patchelf unser binary-Pfad.

Wenn Sie versuchen, eine Binärdatei in linux die Binärdatei zu laden versucht der linker, dann die Bibliotheken, und Sie sollten sich alle in den Pfad und/oder in der richtigen Stelle.Wenn Sie ein problem mit den linker und Sie herausfinden möchten, welchen Weg Sie Ihre Binär-ist auf der Suche für, können Sie mit diesem Befehl:

$ readelf -l myapp | grep interpreter
  [Requesting program interpreter: /lib/ld-linux.so.2]

Wenn Sie ein problem mit den libs, die Befehle, die Ihnen die libs verwendet werden:

$ readelf -d myapp | grep Shared
$ ldd myapp

Diese Liste der libs, dass Ihre binäre Bedürfnisse, aber Sie wissen wahrscheinlich schon, dass das problematisch, da Sie schon nachgeben, Fehler, wie Sie in OP ' s Fall.

"patchelf" funktioniert für viele verschiedene Probleme, die auftreten können, während Sie ein Programm ausführen möchten, mit diesen 2 Problemen.Zum Beispiel, wenn Sie: ELF file OS ABI invalid, es kann behoben werden, indem ein neuer loader (die --set-interpreter Teil des Befehls) wie erkläre ich hier.Ein weiteres Beispiel für das problem zu bekommen No such file or directory beim ausführen einer Datei, die da ist und die ausführbare Datei, wie beispielsweise hier.In diesem besonderen Fall, OP fehlt ein link zu der loader, aber vielleicht in Ihrem Fall, dass Sie nicht über root-Zugriff und können nicht erstellen Sie den link.Einen neuen interpreter würde Ihr problem lösen.

Dank der Eingesetzten Russischen und Michael Pankow für die Erkenntnis und Lösung!

Verwenden LD_PRELOAD:setzen Sie Ihre Bibliothek irgendwo aus dem Mann-lib-Verzeichnisse und ausführen:

LD_PRELOAD='mylibc.so anotherlib.so' program

Siehe: der Wikipedia-Artikel

Erste von alle, die wichtige Abhängigkeit der einzelnen dynamisch verknüpfte Programm ist der linker.Alle Bibliotheken so muss mit der version der linker.

Nehmen wir einfach stehen im Beispiel:Ich habe die newset ubuntu-system), wo ich einige Programm (in meinem Fall ist es D compiler - ldc2).Ich möchte ihn ausführen auf dem alten CentOS, aber wegen der ältere glibc-Bibliothek ist es unmöglich.Ich bekam

ldc2-1.5.0-linux-x86_64/bin/ldc2: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ldc2-1.5.0-linux-x86_64/bin/ldc2)
ldc2-1.5.0-linux-x86_64/bin/ldc2: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ldc2-1.5.0-linux-x86_64/bin/ldc2)

Ich habe so kopieren Sie alle Abhängigkeiten von ubuntu auf centos.Die richtige Methode ist folgende:

Zunächst prüfen wir, ob alle Abhängigkeiten:

ldd ldc2-1.5.0-linux-x86_64/bin/ldc2 
    linux-vdso.so.1 =>  (0x00007ffebad3f000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f965f597000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f965f378000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f965f15b000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f965ef57000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f965ec01000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f965e9ea000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f965e60a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f965f79f000)

linux-vdso.so.1 ist nicht eine Reale Bibliothek und wir don nicht haben zu Pflege über es.

/lib64/ld-linux-x86-64.so.2 ist der linker, der verwendet wird, die vom linux-verlinken Sie die ausführbare Datei mit allen dynamischen libraries.

Rest der Dateien sind Echtzeit-Bibliotheken und alle von Ihnen zusammen mit dem linker kopiert werden müssen, irgendwo in der centos.

Nehmen wir an, alle Bibliotheken und linker sind in "/mylibs" - Verzeichnis.

ld-linux-x86-64.so.2 - wie ich bereits sagte - ist der linker.Es ist keine dynamische Bibliothek, aber statische ausführbare Datei.Sie können es ausführen und sehen, dass es auch einige Parameter, z.B. --library-path (ich werde zurückkehren).

Auf der linux -, dynamisch verknüpfte Programm können frühstückte nur durch seinen Namen, z.B.

/bin/ldc2

Linux lädt Sie ein solches Programm in den Arbeitsspeicher, und prüft, welche linker gesetzt ist.In der Regel, auf 64-bit-system, es ist /lib64/ld-linux-x86-64.so.2 (in Ihrem Dateisystem es ist symbolischer link auf den echten ausführbaren Datei).Dann linux läuft der linker, und es lädt dynamische Bibliotheken.

Sie können auch diesem ein wenig und solchen trick:

/mylibs/ld-linux-x86-64.so.2 /bin/ldc2

Es ist die Methode, die für das linux-spezifische linker.

Und jetzt können wir zurück zu der früher erwähnten parameter --library-path

/mylibs/ld-linux-x86-64.so.2 --library-path /mylibs /bin/ldc2

Es läuft ldc2 und laden die dynamischen Bibliotheken aus /mylibs.

Dies ist die Methode aufrufen, die ausführbare Datei mit der gewählten (nicht-system-Standard -) Bibliotheken.

Können Sie überlegen, Nix http://nixos.org/nix/ ?

Nix unterstützt multi-user-Paket-management:mehrere Benutzer teilen sich die gemeinsame Nix-Shop sicher, benötigen keine root-Privilegien installieren Sie die software, und installieren und verwenden können verschiedene Versionen von Paket.

Setup 1:kompilieren Sie Ihren eigenen glibc ohne dedizierte GCC und verwenden Sie es

Dieses setup funktionieren könnte und geht schnell, da es nicht kompilieren Sie die ganze GCC toolchain, nur glibc.

Aber es ist nicht zuverlässig, wie es verwendet host-C-Laufzeit-Objekte wie crt1.o, crti.o, und crtn.o zur Verfügung gestellt von glibc.Diese wird wie erwähnt auf: https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location Diese Objekte tun, früh-setup, das beruht auf glibc, also ich wäre nicht überrascht, wenn die Dinge stürzte in die wunderbare und sehr subtile Art und Weise.

Für eine zuverlässigere Installation finden Sie unter Setup-2 unten.

Bauen Sie glibc und lokal installieren:

export glibc_install="$(pwd)/glibc/build/install"

git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28
mkdir build
cd build
../configure --prefix "$glibc_install"
make -j `nproc`
make install -j `nproc`

Setup 1:überprüfen Sie die build -

test_glibc.c

#define _GNU_SOURCE
#include <assert.h>
#include <gnu/libc-version.h>
#include <stdatomic.h>
#include <stdio.h>
#include <threads.h>

atomic_int acnt;
int cnt;

int f(void* thr_data) {
    for(int n = 0; n < 1000; ++n) {
        ++cnt;
        ++acnt;
    }
    return 0;
}

int main(int argc, char **argv) {
    /* Basic library version check. */
    printf("gnu_get_libc_version() = %s\n", gnu_get_libc_version());

    /* Exercise thrd_create from -pthread,
     * which is not present in glibc 2.27 in Ubuntu 18.04.
     * https://stackoverflow.com/questions/56810/how-do-i-start-threads-in-plain-c/52453291#52453291 */
    thrd_t thr[10];
    for(int n = 0; n < 10; ++n)
        thrd_create(&thr[n], f, NULL);
    for(int n = 0; n < 10; ++n)
        thrd_join(thr[n], NULL);
    printf("The atomic counter is %u\n", acnt);
    printf("The non-atomic counter is %u\n", cnt);
}

Kompilieren und ausführen mit test_glibc.sh:

#!/usr/bin/env bash
set -eux
gcc \
  -L "${glibc_install}/lib" \
  -I "${glibc_install}/include" \
  -Wl,--rpath="${glibc_install}/lib" \
  -Wl,--dynamic-linker="${glibc_install}/lib/ld-linux-x86-64.so.2" \
  -std=c11 \
  -o test_glibc.out \
  -v \
  test_glibc.c \
  -pthread \
;
ldd ./test_glibc.out
./test_glibc.out

Das Programm gibt die erwarteten:

gnu_get_libc_version() = 2.28
The atomic counter is 10000
The non-atomic counter is 8674

Befehl angepasst https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location aber --sysroot machte es nicht mit:

cannot find /home/ciro/glibc/build/install/lib/libc.so.6 inside /home/ciro/glibc/build/install

also habe ich es entfernt.

ldd die Ausgabe bestätigt, dass die ldd und Bibliotheken, wir haben gerade gebaut werden tatsächlich genutzt wird, wie erwartet:

+ ldd test_glibc.out
        linux-vdso.so.1 (0x00007ffe4bfd3000)
        libpthread.so.0 => /home/ciro/glibc/build/install/lib/libpthread.so.0 (0x00007fc12ed92000)
        libc.so.6 => /home/ciro/glibc/build/install/lib/libc.so.6 (0x00007fc12e9dc000)
        /home/ciro/glibc/build/install/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc12f1b3000)

Die gcc compilation debug-Ausgabe zeigt, dass mein host-runtime-Objekte verwendet wurden, was ist schlecht, wie vorher erwähnt, aber ich weiß nicht, wie das zu umgehen, z.B.es enthält:

COLLECT_GCC_OPTIONS=/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o

Setup 1:ändern glibc

Nun, lassen Sie uns ändern die glibc mit:

diff --git a/nptl/thrd_create.c b/nptl/thrd_create.c
index 113ba0d93e..b00f088abb 100644
--- a/nptl/thrd_create.c
+++ b/nptl/thrd_create.c
@@ -16,11 +16,14 @@
    License along with the GNU C Library; if not, see
    <http://www.gnu.org/licenses/>.  */

+#include <stdio.h>
+
 #include "thrd_priv.h"

 int
 thrd_create (thrd_t *thr, thrd_start_t func, void *arg)
 {
+  puts("hacked");
   _Static_assert (sizeof (thr) == sizeof (pthread_t),
                   "sizeof (thr) != sizeof (pthread_t)");

Dann kompilieren und installieren Sie glibc, und kompilieren Sie und führen unser Programm:

cd glibc/build
make -j `nproc`
make -j `nproc` install
./test_glibc.sh

und wir sehen hacked gedruckt ein paar mal als erwartet.

Dies weiter bestätigt, dass wir doch tatsächlich die glibc, die wir zusammengestellt und nicht den host ein.

Getestet auf Ubuntu 18.04.

Setup 2:crosstool-NG-pristine setup

Dies ist eine alternative zum setup-1, und es ist die richtige setup habe ich erzielt weit:alles ist korrekt, soweit ich das beobachten kann, einschließlich der C-runtime-Objekte wie crt1.o, crti.o, und crtn.o.

In diesem setup erstellen wir eine vollständige gewidmet GCC toolchain nutzt die glibc, die wir wollen.

Der einzige Nachteil dieser Methode ist, dass das bauen dauert länger.Aber ich würde nicht riskieren, eine Produktion setup mit weniger.

crosstool-NG ist eine Reihe von Skripts herunterlädt und kompiliert alles aus der Quelle für uns, einschließlich der GCC, glibc und binutils.

Ja den GCC-build-system ist so schlecht, dass wir müssen ein separates Projekt, für, dass.

Dieses setup ist nicht perfekt, weil crosstool-NG nicht Unterstützung der Erstellung der ausführbaren Dateien ohne zusätzliche -Wl flags,, das fühlt sich komisch an, da wir gebaut haben, GCC selbst.Aber alles scheint zu funktionieren, so ist dies nur eine Unannehmlichkeit.

Holen Sie sich crosstool-NG, konfigurieren und bauen Sie es:

git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
git checkout a6580b8e8b55345a5a342b5bd96e42c83e640ac5
export CT_PREFIX="$(pwd)/.build/install"
export PATH="/usr/lib/ccache:${PATH}"
./bootstrap
./configure --enable-local
make -j `nproc`
./ct-ng x86_64-unknown-linux-gnu
./ct-ng menuconfig
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`

Das bauen dauert etwa dreißig Minuten bis zwei Stunden.

Die einzig erforderliche Konfigurations-option, die ich sehen kann, macht Sie mit Ihrem host-kernel-version zu verwenden, die richtigen kernel-Header.Finden Sie Ihre host-kernel-version mit:

uname -a

das zeigt mir:

4.15.0-34-generic

also in menuconfig Ich mache:

Operating System
- Version of linux

so ich wählen:

4.14.71

das ist der erste gleichwertige oder ältere version.Es ist, älter zu sein, da der kernel ist rückwärts kompatibel.

Setup 2:optionale Konfigurationen

Die .config dass wir erzeugt mit ./ct-ng x86_64-unknown-linux-gnu hat:

CT_GLIBC_V_2_27=y

Um das zu ändern, in menuconfig Aktionen:

C-library
Version of glibc

speichern .config, und weiter mit dem bauen.

Oder, wenn Sie verwenden möchten Ihre eigenen glibc-Quelle, wie z.B.die Verwendung der glibc von den neuesten git, gehen Sie wie diese:

Paths and misc options
- Try features marked as EXPERIMENTAL:auf true gesetzt
C-library
- Source of glibc
  - Custom location:sagen Sie ja
  - Custom location
    - Custom source location:zeigen Sie auf ein Verzeichnis mit glibc-source

wo glibc geklont wurde, wie:

git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28

Setup 2:testen Sie es aus

Wenn Sie einmal gebaut haben, die er toolchain, die Sie wollen, testen Sie es mit:

#!/usr/bin/env bash
set -eux
install_dir="${CT_PREFIX}/x86_64-unknown-linux-gnu"
PATH="${PATH}:${install_dir}/bin" \
  x86_64-unknown-linux-gnu-gcc \
  -Wl,--dynamic-linker="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2" \
  -Wl,--rpath="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib" \
  -v \
  -o test_glibc.out \
  test_glibc.c \
  -pthread \
;
ldd test_glibc.out
./test_glibc.out

Alles scheint zu funktionieren wie in der Setup-1, mit der Ausnahme, dass jetzt die richtige runtime-Objekte verwendet wurden:

COLLECT_GCC_OPTIONS=/home/ciro/crosstool-ng/.build/install/x86_64-unknown-linux-gnu/bin/../x86_64-unknown-linux-gnu/sysroot/usr/lib/../lib64/crt1.o

Setup 2:fehlgeschlagen effiziente glibc kompiliert Versuch

Es scheint nicht möglich, mit crosstool-NG, wie nachfolgend erläutert.

Wenn Sie gerade neu bauen;

env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`

dann werden Ihre änderungen an den benutzerdefinierten glibc-source-Standort berücksichtigt werden, aber es baut alles von Grund auf neu und machen es unbrauchbar für die iterative Entwicklung.

Wenn wir das tun:

./ct-ng list-steps

es gibt einen schönen überblick über die build-Schritte:

Available build steps, in order:
  - companion_tools_for_build
  - companion_libs_for_build
  - binutils_for_build
  - companion_tools_for_host
  - companion_libs_for_host
  - binutils_for_host
  - cc_core_pass_1
  - kernel_headers
  - libc_start_files
  - cc_core_pass_2
  - libc
  - cc_for_build
  - cc_for_host
  - libc_post_cc
  - companion_libs_for_target
  - binutils_for_target
  - debug
  - test_suite
  - finish
Use "<step>" as action to execute only that step.
Use "+<step>" as action to execute up to that step.
Use "<step>+" as action to execute from that step onward.

daher sehen wir, dass es glibc Schritte verflochten mit mehreren GCC Schritte, insbesondere libc_start_files kommt vor cc_core_pass_2, welches ist wahrscheinlich das teuerste Schritt zusammen mit cc_core_pass_1.

Um zu bauen, nur einen Schritt, müssen Sie zuerst den "Speichern " Zwischenstufen" in .config option für den ersten Aufbau:

Paths and misc options
- Debug crosstool-NG
  - Save intermediate steps

und dann können Sie versuchen:

env -u LD_LIBRARY_PATH time ./ct-ng libc+ -j`nproc`

aber leider, die + erforderlich ist erwähnt: https://github.com/crosstool-ng/crosstool-ng/issues/1033#issuecomment-424877536

Beachten Sie jedoch, dass ein Neustart in einem Zwischenschritt setzt das Installationsverzeichnis, in den Zustand, den es hatte, während dieser Schritt.I. e., Sie haben umgebaut libc - aber keine endgültige compiler gebaut mit diesem libc (und daher kein compiler-Bibliotheken wie libstdc++ entweder).

und im Grunde macht immer noch der Wiederaufbau zu langsam machbar sein für die Entwicklung, und ich sehe nicht, wie dies zu überwinden, ohne das patchen crosstool-NG.

Darüber hinaus, ausgehend von der libc Schritt schien nicht zu kopieren über die Quelle wieder aus Custom source location, weiter machen, diese Methode unbrauchbar.

Bonus:stdlibc++

Einen bonus, wenn Sie sind auch interessiert in die C++ standard library: Wie zu Bearbeiten und neu zu erstellen das GCC libstdc++ C++ - standard-Bibliothek Quelle?

Ich bin nicht sicher, ob die Frage noch relevant ist, aber es ist ein anderer Weg, das problem zu lösen:Andockfenster.Man kann installieren eine fast leere container von der Source-Distribution (Die Verteilung für die Entwicklung verwendet), und kopieren Sie die Dateien in den Container.So dass Sie nicht brauchen, um das Dateisystem benötigt für chroot.

@msb gibt eine sichere Lösung.

Ich traf dieses problem auf, wenn ich es Tat import tensorflow as tf in der conda-Umgebung in CentOS 6.5 die hat nur glibc-2.12.

ImportError: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /home/

Ich möchten zu liefern einige details:

Installieren Sie zuerst glibc in Ihrem home-Verzeichnis:

mkdir ~/glibc-install; cd ~/glibc-install
wget http://ftp.gnu.org/gnu/glibc/glibc-2.17.tar.gz
tar -zxvf glibc-2.17.tar.gz
cd glibc-2.17
mkdir build
cd build
../configure --prefix=/home/myself/opt/glibc-2.17  # <-- where you install new glibc
make -j<number of CPU Cores>  # You can find your <number of CPU Cores> by using **nproc** command
make install

Zweitens, Folgen Sie der gleichen Weise zu installieren patchelf;

Dritte, patch, Ihre Python:

[myself@nfkd ~]$ patchelf --set-interpreter /home/myself/opt/glibc-2.17/lib/ld-linux-x86-64.so.2 --set-rpath /home/myself/opt/glibc-2.17/lib/ /home/myself/miniconda3/envs/tensorflow/bin/python

wie erwähnt von @msb

Jetzt kann ich mit tensorflow-2.0 alpha in CentOS 6.5.

ref: https://serverkurma.com/linux/how-to-update-glibc-newer-version-on-centos-6-x/

Wenn Sie genau hinsehen bei der zweiten Ausgabe können Sie sehen, dass der neue Speicherort für die Bibliotheken verwendet wird.Vielleicht gibt es noch fehlenden Bibliotheken, die Teil der glibc.

Ich denke auch, dass alle Bibliotheken, die von Ihrem Programm verwendet werden soll kompiliert, die version von glibc.Wenn Sie Zugriff auf den Quellcode des Programms, eine frische Zusammenstellung scheint die beste Lösung zu sein.

"Beschäftigt Russisch" ist unter die beste Antwort, und ich glaube, alle, die andere vorgeschlagene Antwort kann nicht arbeiten.Der Grund ist einfach, weil, wenn eine Anwendung zum ersten mal erstellt, der alle seine APIs es muss behoben werden zur compile-Zeit.Mit "ldd" u können sehen alle die statisch verknüpften Abhängigkeiten:

ldd /usr/lib/firefox/firefox
    linux-vdso.so.1 =>  (0x00007ffd5c5f0000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f727e708000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f727e500000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f727e1f8000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f727def0000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f727db28000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f727eb78000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f727d910000)

Aber zur Laufzeit, wird firefox auch laden viele andere dynamische Bibliotheken, z.B. (für firefox) gibt es viele "glib"-Gütesiegel Bibliotheken geladen (obwohl statisch gelinkt es keine gibt):

 /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2.2.2
 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0
 /usr/lib/x86_64-linux-gnu/libavahi-glib.so.1.0.2

Manytimes, können Sie sehen, den Namen einer version, soft-verbunden, die in einer anderen version.ZB:

lrwxrwxrwx 1 root root     23 Dec 21  2014 libdbus-glib-1.so.2 -> libdbus-glib-1.so.2.2.2
-rw-r--r-- 1 root root 160832 Mar  1  2013 libdbus-glib-1.so.2.2.2

Dies bedeutet folglich, unterschiedliche version von "Bibliotheken" vorhanden ist, in einem system, das kein problem, da es die gleiche Datei ist, und es wird Kompatibilitäten, wenn Anwendungen mehrere Versionen von Abhängigkeiten.

Daher, auf der system-Ebene alle Bibliotheken fast in Abhängigkeit voneinander, und nur die änderung der Bibliotheken laden Priorität über die Manipulation LD_PRELOAD oder LD_LIBRARY_PATH wird nicht helfen - auch geladen werden kann, zur Laufzeit kann es immer noch abstürzt.

http://lightofdawn.org/wiki/wiki.cgi/-wiki/NewAppsOnOldGlibc

Die beste alternative ist chroot (erwähnt ER nur kurz):aber für diese benötigen Sie, um erstellen Sie die gesamte Umgebung, in der die ursprünglichen binären auszuführen - in der Regel ab /lib, /usr/lib/, /usr/lib/x86 etc.Sie können entweder "Buildroot", oder YoctoProject, oder einfach nur Teer aus einer bestehenden Distribution Umgebung.(wie Fedora/Suse etc).

Wenn ich ausführen wollte, eine Chrom-browser auf Ubuntu precise (glibc-2.15), habe ich die (typisch) Meldung "...libc.so.6:version `GLIBC_2.19' nicht gefunden...".Als ich aber auf die Tatsache, dass Dateien, die nicht benötigt werden permamently, aber nur für den start.So sammelte ich die benötigten Dateien für den browser und sudo und erstellt ein mini-glibc-2.19- Umgebung, den browser gestartet und dann kopiert die original-Dateien zurück wieder.Die benötigten Dateien werden im RAM und in der original glibc ist die gleiche.

as root
the files (*-2.15.so) already exist

mkdir -p /glibc-2.19/i386-linux-gnu

/glibc-2.19/ld-linux.so.2 -> /glibc-2.19/i386-linux-gnu/ld-2.19.so
/glibc-2.19/i386-linux-gnu/libc.so.6 -> libc-2.19.so
/glibc-2.19/i386-linux-gnu/libdl.so.2 -> libdl-2.19.so
/glibc-2.19/i386-linux-gnu/libpthread.so.0 -> libpthread-2.19.so

mkdir -p /glibc-2.15/i386-linux-gnu

/glibc-2.15/ld-linux.so.2 -> (/glibc-2.15/i386-linux-gnu/ld-2.15.so)
/glibc-2.15/i386-linux-gnu/libc.so.6 -> (libc-2.15.so)
/glibc-2.15/i386-linux-gnu/libdl.so.2 -> (libdl-2.15.so)
/glibc-2.15/i386-linux-gnu/libpthread.so.0 -> (libpthread-2.15.so)

das Skript zum ausführen des Browsers:

#!/bin/sh
sudo cp -r /glibc-2.19/* /lib
/path/to/the/browser &
sleep 1
sudo cp -r /glibc-2.15/* /lib
sudo rm -r /lib/i386-linux-gnu/*-2.19.so

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow