Wie erstelle ich glibc unter Arch Linux neu?

Es scheint, als ob MATLAB unter Linux königlich vermasselt ist, weil es "einige Bibliotheken dynamisch mit statischem TLS lädt" , was für mich nichts anderes bedeutet, als dass ich eine Menge Fehler bekomme.

Die vorgeschlagene Lösung besteht darin, glibcmit einem größeren wieder aufzubauen DTV_SURPLUS. Dies lässt mich mit zwei Fragen zurück:

Wie kann ich glibcunter Arch Linux neu erstellen, um die zu erhöhen DTV_SURPLUS? Ich habe mir das PKGBUILD im Bauchmuskelbaum angesehen und DTV_SURPLUSnirgendwo etwas gesehen, daher weiß ich nicht, wo ich die Änderung vornehmen soll.
Welchen Wert setze DTV_SURPLUSich? Vermutlich 2^64wäre es sowohl übertrieben als auch eine schlechte Idee, es auf zu setzen.

Das Problem mit MATLAB kann mit dem folgenden MWE in R2014a gesehen werden:

>> ones(10)*ones(10);
>> doc('help');
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)

Wobei ones(10)*ones(10);die dynamisch verknüpfte libiomp5.soBLAS-Bibliothek geladen wird, die nicht genügend Platz für die dynamisch verknüpfte Bibliothek zu lassen scheint, libxul.sodie für den HTML-basierten Dokumentationsbrowser erforderlich ist. Möglicherweise kann ich dieses spezielle MWE mithilfe einer gepatchten Version von umgehen libiomp5.so, aber das allgemeine Problem besteht weiterhin.

arch-linux glibc

— StrongBad
quelle

Sie sollten wahrscheinlich besser nachsehen, ob es eine Distribution gibt, die glibc bereits mit einem höheren DTV_SURPLUS kompiliert hat - möglicherweise durch Testen in einer VM.

— Goldlöckchen

@goldilocks würde eine Chroot ausreichen oder brauche ich eine volle VM?

— StrongBad

Ich fand dies: stackoverflow.com/questions/19268293/… und dies: mathworks.com/matlabcentral/answers/… . Eine Google-Suche nach "Mit statischem TLS kann kein Objekt mehr geladen werden" liefert Ihnen bestimmt weitere Ideen.

— schaiba

Ich habe in meiner Frage auf die SO-Frage verwiesen, und hier wurde die Idee des Wiederaufbaus glibcvorgeschlagen.

— StrongBad

Der Kernel ist kein Problem, daher können Sie chroot verwenden.

— Goldlöckchen

So kompilieren Sie glibc mit custom neu DTV_SURPLUSund überschreiben die vorhandene Version:

Kopieren Sie /var/abs/core/glibcin ein anderes Verzeichnis, damit Sie darauf schreiben können, ohne root zu sein, und dann cdin dieses Verzeichnis.
Verwenden Sie makepkg -odiese Option, um den Quellcode herunterzuladen und zu extrahieren, ohne ihn zu erstellen (da wir den Quellcode vor dem Erstellen bearbeiten).
Bearbeiten befindet DTV_SURPLUSsich in src/glibc-<version>/sysdeps/generic/ldsodefs.h. Sie können einfach die Nummer in der Zeile ändern, die enthält DTV_SURPLUS.
Bauen Sie es mit makepkg -e.
Installieren Sie die benutzerdefinierte Version mit sudo pacman -U <package file>. Dadurch wird das zuvor installierte offizielle Paket überschrieben.

Wenn Sie die vorhandene Version nicht überschreiben möchten, können Sie chroot verwenden, oder LD_PRELOAD funktioniert auch.

Ich bin mir jedoch nicht sicher, was sein DTV_SURPLUSsoll.

— user4098326
quelle