wie üblich ist libtool?



  • Hallo,

    kurz zum Hintergrund:

    für ursprünglich interne Zwecke habe ich ein Valgrind-Plugin für das Continuous Integration Tool Jenkins (www.jenkins-ci.org) entwickelt und später auch auf der Jenkins-Plattform veröffentlicht (http://goo.gl/GTDXE).

    Eine Komponente dieses Plugin startet beliebige Programme mit Valgrind, die dabei entstehenden XML-Dateien können später ausgewertet werden. Etwas vereinfacht macht das Plugin folgenden Aufruf:

    valgrind --tool=memcheck --xml=yes --xml-file=<output> <program> <args>
    

    Nun ist einer der Anwender mit der Bitte an mich herangetreten, support für libtool einzubauen. Der Aufruf müsste dann so aussehen:

    libtool --mode=execute valgrind --tool=memcheck --xml=yes --xml-file=<output> <program> <args>
    

    Ich muss dazu sagen, dass ich von libtool zuvor noch nie gehört hatte. In keinem der Projekte an denen ich beteiligt war, wurde es eingesetzt. Ich habe mal ein bissel über libtool gelesen, aber mangels Praxis-Erfahrung bin ich mir nicht wirklich sicher, ob ich es verstanden habe und richtig einschätze.

    Ich wollte aus diesem Grund einfach mal nachfragen, wie eure Erfahrungen mit libtool sind. Ich würde nur ungern ein kompliziertes feature einbauen, das so exotisch ist, dass es eigentlich niemand nutzt.

    1. Ist es üblich, dass libtool eingesetzt wird?
    2. Reicht "libtool --mode=execute <program>...", oder sollte ich weitere/beliebige Argumente für libtool berücksichtigen?

    Freue mich auf Antworten 🙂

    Gruß,
    Johannes



  • Ja, libtool ist für Bibliotheken ziemlich üblich. Man findet es praktisch überall, wo sie mit autoconf/automake gebaut werden.

    libtool --mode=execute ist eigentlich nur dann interessant, wenn man sich im Build-Tree einer mit autotools gebauten Bibliothek befindet; dort werden Testprogramme, Generatoren etc. durch Wrapper-Skripte aufgerufen, die LD_LIBRARY_PATH und so auf den betreffenden Build-Tree umbiegen. Da diese Skripte nicht direkt von Debuggern wie gdb oder valgrind benutzt werden können, schreibt man

    libtool --mode=execute valgrind foo/var/programm

    ...wodurch libtool das Skript aufruft, aber an der passenden Stelle den Aufruf foo/bar/.libs/programm durch valgrind foo/bar/.libs/programm ersetzt.

    Wenn ich das richtig im Kopf habe, wird nichts, was nach --mode=foo kommt, von libtool noch als libtool-Option verstanden, also sollte das in der genannten Form ausreichen. Schau aber besser noch mal in die manpage und zieh ggf. ein -- an der passenden Stelle ein.



  • eXistence schrieb:

    Etwas vereinfacht macht das Plugin folgenden Aufruf:

    valgrind --tool=memcheck --xml=yes --xml-file=<output> <program> <args>
    

    Nun ist einer der Anwender mit der Bitte an mich herangetreten, support für libtool einzubauen. Der Aufruf müsste dann so aussehen:

    libtool --mode=execute valgrind --tool=memcheck --xml=yes --xml-file=<output> <program> <args>
    

    [...]
    Ich würde nur ungern ein kompliziertes feature einbauen, das so exotisch ist, dass es eigentlich niemand nutzt.

    so wie ich das anhand des Beispiels verstehe, muss der Anwender einfach nur sein valgrind-Programm durch ein Shellscript ersetzen, dass dann libtool... original-valgrind aufruft.

    In dem Fall müsste dein Programm lediglich den Pfad zu valgrind konfigurierbar machen.



  • seldon schrieb:

    Ja, libtool ist für Bibliotheken ziemlich üblich. Man findet es praktisch überall, wo sie mit autoconf/automake gebaut werden.

    aber zum Glück auch eigentlich NUR da.



  • Ja, das ist dann auch nur die halbe UNIX-Welt. 🙄



  • Marsi Motolami schrieb:

    so wie ich das anhand des Beispiels verstehe, muss der Anwender einfach nur sein valgrind-Programm durch ein Shellscript ersetzen, dass dann libtool... original-valgrind aufruft.

    In dem Fall müsste dein Programm lediglich den Pfad zu valgrind konfigurierbar machen.

    Der Pfad zu valgrind ist bereits konfigurierbar und so ein kleines wrapper-script habe ich auch schon als Lösung vorgeschlagen, allerdings stieß das auf wenig Begeisterung...



  • Dir ist klar, dass du das Problem so oder so generell lösen müssen wirst, oder? Unabhängig davon, welches Buildsystem benutzt wird, müssen, um Testprogramme für Libraries durch valgrind zu jagen, vor dem valgrind-Aufruf die Linkerpfade passend gesetzt werden, und das geschieht eigentlich immer durch ein Skript nach libtool-Art.

    Du kannst jetzt natürlich für jedes Buildsystem ein eigenes kleines Skript ausliefern, aber über die Sinnhaftigkeit dieses Ansatzes kann man sich streiten -- zumal es sich ja jeweils um einen Einzeiler handeln dürfte. Was man in solchen Fällen häufiger sieht, ist eine Konfigurationseinstellung, die ein bisschen wie ein Format-String für strftime aussieht. Etwa

    valgrind --tool=memcheck --xml=yes --xml-file %x %p %a

    ...wobei %x durch den Namen der xml-Datei, %p durch den Programmpfad und %a durch die Argumente ersetzt wird (Bezeichner natürlich beliebig wählbar). Dann kann sich jeder seinen Aufruf kurz selbst zusammenschreiben.


Anmelden zum Antworten