Ich habe den Quagga Dynamic Routing Daemon auf einer CentOS 6-VM verwendet. Ich möchte eine Funktion verwenden, die nur zugänglich ist, wenn das RPM mit dem --multipath=XFlag erstellt wurde. Das von mir verwendete RPM wurde bereits erstellt und aus dem CentOS-Repository bezogen.
Gibt es eine Möglichkeit herauszufinden, ob das RPM mit diesem Flag erstellt wurde, oder muss ich es aus der Quelle erstellen und dieses Flag selbst bereitstellen?
Ich habe das RPM-Quellpaket heruntergeladen und festgestellt, dass der Multipath-Parameter in der mitgelieferten Spezifikationsdatei auf 64 eingestellt ist. Ich könnte es also bei Bedarf einfach selbst erstellen.
Antwort1
Im Allgemeinen bleiben die spezifischen Compiler-Flags, die zum Erstellen einer Userspace-Binärdatei verwendet werden, nicht in der Binärdatei erhalten. Dafür gibt es keinen Grund.
Sie können normalerweise herausfinden, welcher Compiler und welche Compilerversion zum Erstellen der Binärdatei verwendet wurde, indem Sie sie untersuchen. crt0Aber selbst diese Information kann durch die Verwendung eines benutzerdefinierten verschleiert werden crt0.
Vorausgesetzt, es handelt sich nicht um eine statische Binärdatei, können Sie möglicherweise bestimmte Optionen zur Kompilierungszeit/Erstellungszeit ableiten, indem Sie untersuchen, welche gemeinsam genutzten Objekte („.so“) die Binärdatei verwendet und welche Funktionen von jedem gemeinsam genutzten Objekt die Binärdatei verwendet.
Wenn Sie über den Quellcode verfügen, können Sie die Disassemblierungsliste prüfen und mit angemessener Genauigkeit feststellen, ob beim Erstellen der Binärdatei ein bestimmtes Optionsflag verwendet wurde.
Antwort2
Wie @fpmurphy sagte, bleiben die Compiler-Flags normalerweise nicht in der Binärdatei erhalten. Und die Build-Time-Optionen --multipath=Xsind höchstwahrscheinlich Optionen für das ./configureSkript, sodass sie beispielsweise die Generierung einer config.hDatei steuern können, die dann am Build-Prozess teilnimmt, ohne unbedingt die Compiler-Flags zu beeinflussen.
Aber wenn ein Programm viele solcher Optionen hat, gibt esManchmal(nicht immer) eine Möglichkeit, den Status der relevanten Build-Time-Optionen herauszufinden. Wenn diese Informationen verfügbar sind, können sie häufig über programname --versionoder eine ähnliche Option angezeigt werden, die Versionsinformationen anzeigt.
Ich kenne Quagga überhaupt nicht, aberder Dokumentationsabschnitt mit den Terminalmodusbefehlenhat einen vielversprechend aussehenden Befehl:
Befehl:Version anzeigen
Zeigt die aktuelle Version von Quagga und die Informationen zum Build-Host an.
Die „Build-Host-Informationen“ könnten Informationen zu den Build-Time-Optionen enthalten. Oder auch nicht. Aber wenn ich keine einfacheren Informationsquellen hätte, wäre das einer der ersten Orte, an denen ich nachsehen würde.
Wenn die Software verpackt ist und Sie das entsprechende Quellpaket finden können, besteht die allgemeine Idee darin, dass das Quellpaket alle zur Erstellungszeit erforderlichen Konfigurationen enthält, um eine Binärdatei zu erstellen, die mindestens 100 % funktional mit der in den entsprechenden Binärpaketen derselben Distribution verteilten Version identisch ist. Wenn die Distribution die neueren Techniken für „reproduzierbare Builds“ verwendet, kann die resultierende Binärdatei sogar Bit für Bit identisch sein.
Daher ist das Quellpaket (und im Fall eines RPM .specinsbesondere dessen Datei) eine gute Informationsquelle zu den zur Build-Zeit im entsprechenden Binärpaket verwendeten Optionen.
Angenommen, das Quell-RPM, dessen .specDatei Sie überprüft haben, stammt ebenfalls aus dem CentOS-Repository und hat dieselbe Version wie Ihre Binärdatei, dann wäre die Standardannahme, dass ja --multipath=64bei der Erstellung des binären RPM verwendet wurde. Wenn Sie feststellen, dass dies nicht der Fall ist, wäre das ein sehr guter Grund, einen Fehlerbericht zu erstellen oder sich andernfalls an den Distributor zu wenden und die Diskrepanz zu melden.