[LINUX] Einführung in die Konfiguration einer selbst erstellten Bibliothek

Ich habe configure vor langer Zeit eingeführt, aber ich habe vergessen, wie es geht. Ich werde es dem Github-Code hinzufügen, also versuchen wir es zu konfigurieren!

Was ist konfigurieren?

Jedes Mal, wenn ich selbst ein Makefile schreibe, ändere ich den Bibliothekspfad und die Verknüpfung entsprechend der Umgebung und suche nach dem Headerpfad. Und ** Wartung ist für jede Umgebung schwierig. ** ** ** ** → konfigurieren ** löst dies

Wenn Sie configure richtig eingestellt haben, wird all dies ohne Erlaubnis gelöst.

Das ist eine häufige Erklärung.

Die Funktionen und Eindrücke, die ich denke, sind in 3 Zeilen unten zusammengefasst.

Ich habe am Ende verschiedene Dinge geschrieben.

Grundlegende Vorgehensweise

  1. Installieren Sie die erforderlichen Pakete (sollte Autotool, Libtool gewesen sein)
  2. Führen Sie Autoscan im obersten Verzeichnis Ihres Codes aus
  3. configure.scan kann durchgeführt werden, benennen Sie es also in configure.ac um
  4. Führen Sie autoreconf --install * 1 aus
  5. Fügen Sie Makefile.am hinzu
  6. Führen Sie automake aus (automake --add-fehlt nur am Anfang)
  7. Korrigieren Sie configure.ac und Makefile.am für den angezeigten Fehler.
  8. Wiederholen Sie die Schritte 4 bis 7, um den Fehler bei der Ausführung des Befehls zu beheben.

Wenn der Fehler dann verschwindet und ./configure → make ausgeführt werden kann, ist er abgeschlossen.

Das Verfahren ist behoben, aber ich frage mich, ob es schwierig ist, configure.ac und Makefile.am zu erreichen. Makefile.am und configure.ac sollten auf vorhandenem Code und OSS basieren.

Ich werde beschreiben, was ich nach dem nächsten getan habe.

Über Makefile.am

Die Grundlagen sind so

Beispiel

```Makefile.am`


SUBDIRS = lib include

```lib:Makefile.am:lib`


# Wenn Sie keine Installation benötigen
noinst_LTLIBRARIES = libtimelog.la
# Bei der Installation
lib_LTLIBRARIES = libtimelog.la

# Code-Spezifikation
libtimelog_la_SOURCES = timetestlog.c

Sie können wählen, ob auch Header und Binärdateien installiert werden sollen. Wenn Sie es nicht installieren, ist es üblich, noinst.

``Makefile.am`


# Bei der Installation
include_HEADERS= libtimelog.la

# Bei der Installation
bin_PROGRAMS = test

Es scheint, dass die Beschreibungsmethode hier verschiedene Macken aufweist, daher ist es notwendig, sie gegebenenfalls zu untersuchen.

Es scheint auch möglich zu sein, eine gemeinsame Definition wie diese zusammenzustellen

```am.conf`


common header deifinition
# Legen Sie diese Datei oben ab
AM_CPPFLAGS=-I$(top_srcdir)/include
INCLUDES_PATH=$(top_srcdir)/include

Makefile.bin Seite


# Laden Sie diese Einstellung mit include
include $(top_srcdir)/am.conf

Ich erinnere mich, dass ich sowohl dynamisch als auch statisch gemacht habe, aber das ist eine weitere Gelegenheit.

2018/05/15

So machen Sie sowohl dynamisch als auch statisch: Es sieht gut aus, nur LDFLAGS hinzuzufügen. Zum Beispiel ist es in Ordnung, wenn Sie nur rpath wie folgt übergeben. Wenn entweder ** -shared oder -static angehängt ist, wird einem Vorrang eingeräumt, so dass es anscheinend darum geht, auch nicht ** anzuhängen. Bestätigter Betrieb unter Ubuntu 18.04

```lib:Makefile.am:lib`


libtimelog_la_SOURCES = timetestlog.c
libtimelog_la_LDFLAGS=-rpath $(libdir)

Über configure.ac

Was zu tun ist

Im letzteren Fall tritt während automake und autoreconf ein Fehler auf, sodass Sie sie einzeln zerstören können. Es scheint jedoch schwierig zu sein, wenn Sie nicht daran gewöhnt sind.

Ich bin auf Folgendes gestoßen

・ Der folgende Fehler tritt während des salzigen Automakes auf

error: no proper invocation of AM_INIT_AUTOMAKE was found.

→ Fügen Sie configure.ac Folgendes hinzu, um damit umzugehen

```configure.am`


AM_INIT_AUTOMAKE([foreign -Wall -Werror])
AM_PROG_AR

-Der folgende Fehler für den lib-Ordner in autoreconf

libtoolize: Consider adding AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding -I m4' to ACLOCAL_AMFLAGS in Makefile.am.

→ Fügen Sie configure.ac Folgendes hinzu, um damit umzugehen

```configure.am`


LT_INIT

Jetzt arbeite ich gut.

Beispielsweise erkennt eine Bibliothek wie pthread es während des Autoscans und fügt es ohne Erlaubnis hinzu und verknüpft es mit configure.ac. Es ist also einfach, nur die von Ihnen erstellte Bibliothek zu kennen.

Die einzige nützliche Funktion, an die ich mich erinnerte

Sie können Ihre eigenen ./configure-Optionen erstellen. (Und Sie können es auch richtig mit ./configure --help überprüfen. Persönlich war ich beeindruckt)

Wenn Sie beispielsweise das Debuggen mit --enable-debug aktivieren / deaktivieren möchten, verwenden Sie AC_ARG_ENABLE und AC_DEFINE.

AC_ARG_ENABLE erkennt die Aktivierungsoption. AC_ARG_ENABLE (Option, Hilfemeldung, Ausführungsshell, wenn Option angegeben, Standardwert)

AC_DEFINE übergibt eine Definition wie -DXXX AC_DEFINE (Name definieren, Wert definieren, [Beschreibung])

Es fühlt sich an wie.

Ich habe die treadsafe-Option wie folgt hinzugefügt.

```configure.am`


#AC_ARG_ENABLE( option, help message, script code for this option, default value)
AC_ARG_ENABLE(threadsafe,
[  --enable-threadsafe      enable to share handle between threads [[default=no]]],
[\
#
case "${enableval}" in
 yes) enable_threadsafe=yes ;;
 *)   AC_MSG_ERROR(bad value for --enable-) ;;
esac],
enable_threadsahe=no)

#check flag and set defile
if test x"${enable_threadsafe}" = x"yes"; then
  AC_DEFINE(THREAD_SAFE, 1, [Define to 1 if you want to ensure thread safe])
else
echo "libnotify is disabled"
fi

Die Hilfe sieht so aus.

./configure --help
...
  --enable-threadsafe      enable to share handle between threads [default=no]

Es wird sofort so! Dies ist auch praktisch, da Debug-Optionen einfach zu verwalten sind.

Ich habe eine Zusammenfassung über die Optionen gemacht. Dies ist hier.

Persönlicher Eindruck

guter Punkt

――Es ist wirklich einfach, die Standardbibliothek ohne Erlaubnis zu verknüpfen (ich vergesse, rt oder etwas mit hoher Wahrscheinlichkeit hinzuzufügen). ――Ich bin froh, dass Sie es mit weniger Beschreibung schaffen können

Es ist ein persönliches Hobby, aber ich denke, es lohnt sich, es auch am Ende vorzustellen. Die Kompilierungsoption ist praktisch, aber schwierig zu teilen, da sie dem Ersteller einen Vorgeschmack gibt. Ich vergesse, auch wenn ich es selbst mache. Dies kann mit ./configure --help ohne ** Dokumentationspflege bestätigt werden. ** ** ** Leute, die die Implementierung mögen, schreiben keine Dokumentation, aber wenn es darum geht, Hilfe oder Verwendung zu schreiben, schreiben sie sie richtig.

Punkte, um die man sich Sorgen machen muss

――Es ist schwierig, den Fehler in dem Teil zu verfolgen, der Ihnen zum Zeitpunkt der Einführung überlassen wurde

Wie bei allen anvertrauten Werkzeugen ist es schwierig, die Ursache zu untersuchen, wenn etwas, das die Funktionsweise im Inneren nicht versteht, nicht gut funktioniert. Als ich früher versuchte, verschiedene Dinge ernsthaft einzuführen, habe ich viel im Konfigurationsskript debuggt. Ich erinnere mich, dass ich große Probleme hatte, die Ursache zu finden.

In config.log befindet sich ein Protokoll. Wenn Sie also über ein ordnungsgemäßes OSS verfügen, ist dies allein ein Sprungbrett, um die Ursache aufzuspüren. Wenn Sie es selbst machen, werden Sie viele Dinge bezweifeln.

Bei libtool bin ich mir nicht sicher.

Fälle, in denen ich Teil 1 getroffen habe. Es wurde erkannt, dass es funktionieren würde, wenn das eigentliche libtool und ltmain.sh platziert würden, aber wenn es in einer libtool-Umgebung mit hoher Version verwendet wird, schlägt make fehl. (Erstellt mit Ubuntu 14.04 → Fehler beim Erstellen mit Ubuntu 18.04) → Löschen Sie in diesem Fall libtool und ltmain.sh und führen Sie autoreconf aus, um das Problem zu lösen.

Teil 2. Im Gegenteil, als ich den Code in die alte libtool-Umgebung brachte, wurde ./configure-> make ausgeführt, aber Nach dem Bearbeiten von configure.ac → Ausführen von autoreconf können weder build noch autoreconf ausgeführt werden. (Ich habe Ubuntu 18.04 → Cent OS 5.1 ausprobiert)

Wenn Sie nichts tun, können Sie ./configure and make ausführen, aber hmm, da bin ich mir nicht sicher.

Es ist einfach, dem Problem zu folgen, da es hier mit einem geeigneten OSS ordnungsgemäß erstellt wurde. Ich bin skeptisch gegenüber verschiedenen Dingen, wenn ich es selbst mache, also denke ich, dass es einer der Punkte ist, an denen die Schwelle etwas hoch ist.

Es ist bequem zu installieren und zu funktionieren, aber es ist schwer, sich darauf einzulassen, so dass es so aussieht, als ob Ihr Geschmack anders sein wird. Wie ist OSS in der Welt? Ich habe gesehen, wie du die Version überprüft hast

Wenn Sie irgendwelche Probleme haben, werde ich sie hier auflisten. TIPPS mit configure (Obwohl es ein Mülleimer ist)

Beispielcode

https://github.com/developer-kikikaikai/speedtest

Die unten vorgestellte Bibliothek wurde konfiguriert. https://qiita.com/developer-kikikaikai/items/d8839eae7f4491e01671

Referenz

http://nopipi.hatenablog.com/entry/2013/01/14/025509 https://qiita.com/impepc/items/1bfdfe8ad741def10948 http://capm-network.com/?tag=autotools%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E6%A7%8B%E6%88%90%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB https://stackoverflow.com/questions/28972112/autotools-setup-for-static-and-shared-libraries?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa http://d.hatena.ne.jp/kakurasan/20090512/p1

Recommended Posts

Einführung in die Konfiguration einer selbst erstellten Bibliothek
Empfehlung der binpacking Bibliothek von Python
Tensorflows praktische Bibliothek TF-Slim
Liste der selbst erstellten Docker-Bilder
Einführung in die TestData-Erstellungsbibliothek Mimesis
Beginn des selbst erstellten Betriebssystems 1. Aufbau der Umgebung