ld.so.cache auslesen

[tntnet_]

strace ist ein sehr hilfreiches Tool bei so etwas. Es zeigt die Systemaufrufe an, welche ein Prozess ausführt. Damit bekommt man Hinweise, wie das Tool seine Aufgabe erfüllt.

strace -o ldconfig.strace -f /sbin/ldconfig -p zeigt, dass die Datei /etc/ld.so.cache gelesen wird. Und die Datei ist binär. Es sieht also tatsächlich in dem Fall so aus, dass es keine API dafür gibt.

Prinzipiell ist die Idee genau richtig. Viel zu oft werden aus C- oder C++-Programmen irgendwelche Kommandozeilentools aufgerufen statt die Systemaufrufe zu verwenden. Parsen der Ausgabe von Kommandozeilentools ist Fehleranfällig und das Starten dieser sehr ineffizient. Die API ist immer zu bevorzugen.

[kurze_frage]

die Datei ist ld.so.cache binär, ja,
die Websuch hat of das 'kompilierte Informationen' ergeben.

also gibts entweder ein API oder eine Formatbeschreibung, nur hab ich beides nicht gefunden

es kann ja nicht sein das die Datei 'properitär' ist und ldconfig der einzige Zugang ist.
die Informationen aus ld.so.cache verwenden ja auch andere Programme.

nur ich weis schon nicht mehr mit welechen Keywords ich die Suchmaschiene füttern soll

[pferdefreund]

ich mach das bei Eigenanwendung eigentlich sehr gerne mit popen usw.
Ich teile, so gut es immer geht, die Anwendung von der GUI und kann dann, so x nicht läuft oder wenn ich per ssh oder was auch immer auf der Kiste bin, das Programm halt im Kommandozeilenmodus verwenden. Der Overhead für das einmalige Starten ist dabei zu vernachlässigen. Natürlich im Massengeschäft ist das schon interessant - aber ansonsten ?

Was die Struktur der ld.so.cache angeht - da hilft wohl wirklich nur der Quelltext des ldconfig weiter. Wenn der es ausgeben kann, muß er auch irgendwo beschreiben, wie die Datei aussieht.

[nman]

kurze_frage schrieb:

es kann ja nicht sein das die Datei 'properitär' ist und ldconfig der einzige Zugang ist.
die Informationen aus ld.so.cache verwenden ja auch andere Programme.

Klar, aber warum meinst du, dass diese anderen Programme selbst die ld.so.cache parsen müssen?

[kurze_frage]

nman schrieb:

kurze_frage schrieb:

es kann ja nicht sein das die Datei 'properitär' ist und ldconfig der einzige Zugang ist.
die Informationen aus ld.so.cache verwenden ja auch andere Programme.

Klar, aber warum meinst du, dass diese anderen Programme selbst die ld.so.cache parsen müssen?

desswegen meine Frage nach einem API, ich denke nicht das jedes Programm selber mit einem eigenen Parser relaisiert wird. das die popen aufrufe machen kann ich mir auch nicht vorstellen.
das ganze wird wohl irgendwo in der glibc, bzw in dessen Source Packet, stecken, nur bin ich gestern sehr unerfolgreich gewesen da irgenwas zu finden.

[firefly]

da ld-linux.so die Cache Datei auch liest, findest du eventuell in den sourcen von ld-linux.so wie die Datei aufgebaut ist.

Wobei sich mir dir frage stellt für was du die Informationen in dieser cache Datei benötigst oder glaubst zu benötigen

[tntnet]

pferdefreund schrieb:

ich mach das bei Eigenanwendung eigentlich sehr gerne mit popen usw.
Ich teile, so gut es immer geht, die Anwendung von der GUI und kann dann, so x nicht läuft oder wenn ich per ssh oder was auch immer auf der Kiste bin, das Programm halt im Kommandozeilenmodus verwenden. Der Overhead für das einmalige Starten ist dabei zu vernachlässigen. Natürlich im Massengeschäft ist das schon interessant - aber ansonsten ?

Und genau das ist die falsche Einstellung. Ich mache eher eine Klasse, die eine Aufgabe erfüllt. Dann kann man eine GUI Applikation schreiben, die diese Klasse verwendet. Und damit das über die Kommandozeile auch funktioniert, schreibt man dann eine kleine Kommandozeilenapplikation, die diese Klasse verfügbar macht.

Es ist nicht nur die Performance, sondern auch das Parsen der Ausgabe, was Probleme bereiten kann. Parsen der Ausgabe ist unzuverlässig. Von der mangelnden Kontrolle über Fehlerzustände ganz zu schweigen. Fragst Du immer schön den Fehlercode des Kommandozeilenprogrammes ab? Und was machst Du mit der Zahl? Eine API hat da eben viel mehr Möglichkeiten, einen Fehler zu verarbeiten.

[kurze_antwort]

tntnet schrieb:

Es ist nicht nur die Performance, sondern auch das Parsen der Ausgabe, was Probleme bereiten kann. Parsen der Ausgabe ist unzuverlässig. Von der mangelnden Kontrolle über Fehlerzustände ganz zu schweigen. Fragst Du immer schön den Fehlercode des Kommandozeilenprogrammes ab? Und was machst Du mit der Zahl? Eine API hat da eben viel mehr Möglichkeiten, einen Fehler zu verarbeiten.

Du hast da was grundlegend nicht verstanden.

Unix philosophy schrieb:

Write programs to handle text streams, because that is a universal interface.

Text parsen geht immer. Vielleicht wird ldconfig mal ersetzt -- egal, der Ersatz bietet immer noch ein Legacy-Format an. Hat jemand ein spezielles ldconfig? Super, arbeitet perfekt zusammen. Selbst ein System ohne ldconfig kann ein Fake-ldconfig-Shellscript anbieten. Wunderbar.

APIs veralten, werden ersetzt, sind schlecht konfigurierbar, haben nur Nachteile. Performance ist allermeistens kein Thema und wenn, dann hat man mit dem Textinterface einen viel besseren Ansatzpunkt, das Programm zu tunen.

Was am Rückgabewert Probleme machen soll ist mir nicht ersichtlich.

[tntnet]

kurze_antwort schrieb:

tntnet schrieb:

Es ist nicht nur die Performance, sondern auch das Parsen der Ausgabe, was Probleme bereiten kann. Parsen der Ausgabe ist unzuverlässig. Von der mangelnden Kontrolle über Fehlerzustände ganz zu schweigen. Fragst Du immer schön den Fehlercode des Kommandozeilenprogrammes ab? Und was machst Du mit der Zahl? Eine API hat da eben viel mehr Möglichkeiten, einen Fehler zu verarbeiten.

Du hast da was grundlegend nicht verstanden.

Unix philosophy schrieb:

Write programs to handle text streams, because that is a universal interface.

Text parsen geht immer. Vielleicht wird ldconfig mal ersetzt -- egal, der Ersatz bietet immer noch ein Legacy-Format an. Hat jemand ein spezielles ldconfig? Super, arbeitet perfekt zusammen. Selbst ein System ohne ldconfig kann ein Fake-ldconfig-Shellscript anbieten. Wunderbar.

APIs veralten, werden ersetzt, sind schlecht konfigurierbar, haben nur Nachteile. Performance ist allermeistens kein Thema und wenn, dann hat man mit dem Textinterface einen viel besseren Ansatzpunkt, das Programm zu tunen.

Was am Rückgabewert Probleme machen soll ist mir nicht ersichtlich.

Es geht mir hier nicht um den konkreten Fall "ldconfig". Da habe ich ja schon geschrieben, dass das die richtige Lösung ist, die Ausgabe zu parsen.

Ich denke da an andere Dinge wie beispielsweise das Auslesen der IP-Adresse einer Interfaces. Dort könnte ich die Ausgabe von ifconfig parsen (ach nein - das ist ja veraltet, obwohl ja Kommandozeilentools nicht veralten sollen - ip ist heute das richtige tool). Oder eben die entsprechenden Systemaufrufe nutzen. Beim parsen musst Du aufpassen, dass jemand möglicherweise seine Sprache anders eingestellt hat als Du.

Auch sehe ich des öfteren C oder C++ Programme, die die Ausgabe von "ls" parsen. Das ist ganz schlecht. Man denke beispielsweise an Dateinamen mit Leerzeichen.

Die Unix Philosophie finde ich ja super. Aber Du musst die Lösung auf der richtigen Ebene suchen. Es ist so leicht ein opendir/readdir zu machen.

[kurze_frage]

natürlich verwendet man APIs wenn es sie gibt und es Sinn macht.
z.B. warum sollte sonst irgendein Programm sonst eine der exestierenden libelf Implementierungen verwenden statt die Ausgabe von objdump, mn, readelf oder ähnlichen zu parsen.

ad ldconfig -p
warum soll ich z.B einen String für die Architektur Information parsen?
und welche Architektur Strings gibt es überhaupt. man ldconfig sagt dir das gar nicht.
das geht effizienter wenn man den richtigen Header hat, und die entsprechenden Flags findet.

in der glibc hab ich den Code für ldconfig jetzt gefunden, ob der geteilt wird und öffentlich zugänglich ist muss ich aber erst noch rausfinden, ich fürchte aber das dies nicht der Fall ist.