man dpkg-buildflags (1): liefert Bauschalter zum Einsatz beim Paketbau

ÜBERSICHT

dpkg-buildflags [Option …] [Befehl]

BESCHREIBUNG

dpkg-buildflags ist ein Werkzeug, das zum Abfragen der zu verwendenden Kompilierungsschalter für den Bau von Debian-Paketen eingesetzt wird. Die Standardschalter werden vom Lieferanten definiert, sie können auf mehrere Arten erweitert/überschrieben werden:

1.: systemweit mit /etc/dpkg/buildflags.conf
2.: für den aktuellen Benutzer mit $XDG_CONFIG_HOME/dpkg/buildflags.conf, wobei $XDG_CONFIG_HOME standardmäßig auf $HOME/.config gesetzt ist
3.: temporär durch den Benutzer mittels Umgebungsvariablen (siehe Abschnitt UMGEBUNG)
4.: dynamisch durch den Paketverwalter mittels Umgebungsvariablen, die über debian/rules gesetzt wurden (siehe Abschnitt UMGEBUNG)

Die Konfigurationsdateien können zwei Arten von Direktiven enthalten:

SET Schalter Wert: Überschreibt den Schalter namens Schalter, um den Wert Wert zu erhalten.
STRIP Schalter Wert: Aus dem Schalter namens Schalter alle in Wert aufgeführten Bauschalter entfernen
APPEND Schalter Wert: Erweitert den Schalter namens Schalter durch Anhängen der in Wert angegebenen Optionen. Ein Leerzeichen wird vor den angehängten Wert vorangestellt, falls der derzeitige Wert nicht leer ist.
PREPEND Schalter Wert: Erweitert den Schalter namens Schalter durch Voranstellen der in Wert angegebenen Optionen. Ein Leerzeichen wird hinter den vorangestellten Wert angehängt, falls der derzeitige Wert nicht leer ist.

Die Konfigurationsdateien können Kommentare auf Zeilen enthalten, die mit einer Raute (#) beginnen. Leere Zeilen werden auch ignoriert.

BEFEHLE

--dump

Auf der Standardausgabe alle Kompilierschalter und ihre Werte ausgeben. Es wird ein Schalter pro Zeile ausgegeben, wobei der Werte durch ein Gleichheitszeichen ("Schalter=Wert") abgetrennt wird. Dies ist die Standardaktion.

--list

Gibt die Liste der vom aktuellen Lieferanten unterstützen Schalter (eine pro Zeile) aus. Lesen Sie den Abschnitt UNTERSTÜTZTE SCHALTER für weitere Informationen über sie.

--status

Alle Informationen anzeigen, die zum Verständnis des Verhaltens von dpkg-buildflags nützlich sein können (seit Dpkg 1.16.5): relevante Umgebungsvariablen, aktueller Lieferant, Zustand der Funktionsschalter. Auch die entstehenden Compiler-Schalter mit ihrem Ursprung werden ausgeben.

Dies ist zur Ausführung in debian/rules gedacht, so dass das Bauprotokoll einen klaren Nachweis der verwandten Bauschalter enthält. Dies kann zur Diagnose von Problemen in Zusammenhang mit diesen nützlich sein.

--export=Format

Auf der Standardausgabe Befehle ausgeben, die dazu verwandt werden können, alle Kompilierschalter für bestimmte Werkzeuge zu exportieren. Falls der Wert von Format nicht angegeben wird, wird sh angenommen. Nur Kompilierschalter, die mit einem Großbuchstaben beginnen, werden aufgenommen. Bei allen anderen wird angenommen, dass sie für die Umgebung nicht geeignet sind. Unterstützte Formate:

sh: Shell-Befehle, um alle Kompilierungsschalter in der Umgebung zu setzen und zu exportieren. Die Schalterwerte werden maskiert, so dass die Ausgabe für Auswertung durch eine Shell bereit ist.
cmdline: Argumente, die an die Befehlszeile eines Bauprogrammes übergeben werden, um alle Übersetzungsschalter zu verwenden (seit Dpkg 1.17.0). Die Schalterwerte werden in Shell-Syntax maskiert.
configured (konfiguriert): Dies ist ein historischer Alias für cmdline.
make: Make-Direktiven, um alle Kompilierungsschalter in der Umgebung zu setzen und zu exportieren. Die Ausgabe kann in ein Makefile-Fragment geschrieben und mit einer include-Direktive ausgewertet werden.

--get Schalter

Gibt den Wert des Schalters auf der Standardausgabe aus. Beendet sich mit 0, falls der Schalter bekannt ist, andernfalls mit 1.

--origin Schalter

Gibt den Ursprung des von --get gelieferten Werts aus. Beendet sich mit 0, falls der Schalter bekannt ist, andernfalls mit 1. Der Ursprung kann einer der folgenden Werte sein:

vendor: der ursprünglich vom Lieferanten gesetzte Schalter wird zurückgeliefert
system: der Schalter wurde durch eine systemweite Konfiguration gesetzt/verändert
user: der Schalter wurde durch eine benutzerspezifische Konfiguration gesetzt/verändert
env: der Schalter wurde durch eine umgebungsspezifische Konfiguration gesetzt/verändert

--query-features Bereich

Gibt die Funktionalitäten, die für den übergebenen Bereich aktiviert sind, aus (seit Dpkg 1.16.2). Die einzigen unter Debian und abgeleiteten Distributionen derzeit erkannten Bereiche sind qa, reproducible, sanitize und hardening. Lesen Sie den Abschnitt FUNKTIONALITÄTSBEREICHE für weitere Details. Beendet sich mit 0, falls der Bereich bekannt ist, andernfalls mit 1.

Das Ausgabeformat ist im RFC822-Format, mit einem Abschnitt pro Funktionalität. Beispiel:

  Feature: pie
  Enabled: no
  Feature: stackprotector
  Enabled: yes

--help

Zeige den Bedienungshinweis und beende.

--version

Gebe die Version aus und beende sich.

UNTERSTÜTZTE SCHALTER

CFLAGS: Optionen für den C-Compiler. Der vom Lieferanten gesetzte Standardwert enthält -g und die Standard Optimierungsstufe (normalerweise -O2 oder -O0, falls die Umgebungsvariable DEB_BUILD_OPTIONS noopt definiert.
CPPFLAGS: Optionen für den C-Präprozessor. Standardwert: leer
CXXFLAGS: Optionen für den C++-Compiler. Identisch zu CFLAGS.
OBJCFLAGS: Optionen für den Objective-C-Compiler. Identisch zu CFLAGS.
OBJCXXFLAGS: Optionen für den Objective-C++-Compiler. Identisch zu CXXFLAGS.
GCJFLAGS: Optionen für den GNU-Java-Compiler (gcj). Eine Untermenge von CFLAGS.
FFLAGS: Optionen für den Fortran-77-Compiler. Eine Untermenge von CFLAGS.
FCFLAGS: Optionen für den Fortran-9x-Compiler. Identisch zu FFLAGS.
LDFLAGS: Optionen die beim Linken von Programmen oder Laufzeitbibliotheken an den Compiler weitergegeben werden (falls der Linker direkt aufgerufen wird, müssen -Wl und , aus diesen Optionen entfernt werden). Standardmäßig leer.

Neue Schalter können in Zukunft hinzugefügt werden, falls die Notwendigkeit aufkommt (beispielsweise, um weitere Sprachen zu unterstützen).

FUNKTIONALITÄTSBEREICHE

Jede Bereichsfunktionalität kann durch den entsprechenden Bereichswert in den Umgebungsvariablen DEB_BUILD_OPTIONS und DEB_BUILD_MAINT_OPTIONS mit den '+'- und '-'-Schaltern aktiviert und deaktiviert werden. Soll beispielsweise für hardening die "pie"-Funktionalität aktiviert und die "fortify"-Funktionalität deaktiviert werden, können Sie Folgendes in debian/rules verwenden:

export DEB_BUILD_MAINT_OPTIONS=hardening=+pie,-fortify

Die spezielle Funktionalität all (in allen Bereichen gültig) kann dazu verwandt werden, alle Bereichsfunktionalitäten auf einmal zu aktivieren oder zu deaktiveren. Um daher alles im Bereich hardening zu deaktiveren und nur "format" und "fortify" zu aktiveren, kann Folgendes eingesetzt werden:

export DEB_BUILD_MAINT_OPTIONS=hardening=-all,+format,+fortify

QS

Mehrere Optionen zur Kompilierung (Details weiter unten) können verwandt werden, um dabei zu helfen, Probleme im Quellcode oder im Bausystem zu erkennen.

bug: Diese Einstellung (standardmäßig deaktiviert) fügt Warnoptionen hinzu, die zuverlässig problematischen Quellcode erkennen. Diese Warnungen sind fatal. Die einzigen derzeit unterstützten Schalter sind CFLAGS und CXXFLAGS, wobei die Schalter auf -Werror=array-bounds, -Werror=clobbered, -Werror=implicit-function-declaration und -Werror=volatile-register-var gesetzt werden.
canary: Diese Einstellung (standardmäßig deaktiviert) fügt Pseudo-Kanarienvögel-Optionen zu den Bauschaltern hinzu, so dass die Bauprotokolle überprüft werden können, wie die Bauschalter sich fortpflanzen. Dies erlaubt, Auslassungen in den normalen Bauschaltereinstellungen zu finden. Derzeit werden nur die Schalter CPPFLAGS, CFLAGS, OBJCFLAGS, CXXFLAGS und OBJCXXFLAGS unterstützt, wobei die Schalter auf -D__DEB_CANARY_Schalter_Zufallskennung__ gesetzt werden, und LDFLAGS, das auf -Wl,-z,deb-canary-Zufallskennung gesetzt wird.

Bereinigung

Mehrere Kompilierzeit-Optionen (weiter unten beschrieben) können dazu verwandt werden, ein erstelltes Programm vor Speicherverfälschungsangriffen Speicherlecks, Verwendung nach Freigabe, Daten-Zugriffswettläufen (»races«) in Threads und Fehlern durch undefiniertes Verhalten zu bereinigen.

address: Diese Einstellung (standardmäßig deaktiviert) fügt -fsanitize=address zu LDFLAGS und -fsanitize=address -fno-omit-frame-pointer zu CFLAGS und CXXFLAGS hinzu.
thread: Diese Einstellung (standardmäßig deaktiviert) fügt -fsanitize=thread zu CFLAGS, CXXFLAGS und LDFLAGS hinzu.
leak: Diese Einstellung (standardmäßig deaktiviert) fügt -fsanitize=leak zu LDFLAGS hinzu. Sie wird automatisch deaktiviert, falls entweder die Funktionalitäten address oder thread aktiviert werden, da diese sie einschließen.
undefined: Diese Einstellung (standardmäßig deaktiviert) fügt -fsanitize=undefined zu CFLAGS, CXXFLAGS und LDFLAGS hinzu.

Härtung

Mehrere Kompilierzeit-Optionen (weiter unten beschrieben) können dazu verwandt werden, ein erstelltes Programm gegen Speicherverfälschungsangriffe zu härten, oder zusätzliche Warnungsmeldungen während der Übersetzung auszugeben. Sie werden für Architekturen, die diese unterstützen, standardmäßig aktiviert; die Ausnahmen sind unten angegeben.

format

Diese Einstellung (standardmäßig aktiviert) fügt -Wformat -Werror=format-security zu CFLAGS, CXXFLAGS CXXFLAGS, OBJCFLAGS und OBJCXXFLAGS hinzu. Damit wird über inkorrekte Formatzeichenkettenverwendungen gewarnt und zu einem Fehler führen, wenn Formatfunktionen deart verwandt werden, dass daraus ein mögliches Sicherheitsproblem werden könnte. Derzeit warnt dies über Aufrufe auf printf- und scanf-Funktionen, bei denen die Formatzeichenkette nicht eine reine Zeichenkette ist und es keine Formatargumente gibt, wie in printf(foo); statt printf("%s", foo);. Dies könnte ein Sicherheitsproblem sein, falls die Formatzeichenkette aus einer unvertrauenswürdigen Eingabe stammt und '%n' enthält.

fortify

Diese Einstellung (standardmäßig aktiviert) fügt -D_FORTIFY_SOURCE=2 zu CPPFLAGS hinzu. Während der Code-Erstellung hat der Compiler umfangreiche Informationen über Puffergrößen (wo möglich) und versucht, unsichere unbegrenzte Pufferfunktionsaufrufe durch längenbegrenzte zu ersetzen. Das ist besonders für alten, verkramten Code nützlich. Zusätzlich werden Formatzeichenketten in schreibbarem Speicher, die '%n' enthalten, blockiert. Falls eine Anwendung von solchen Formatzeichenketten abhängt, müssen dafür andere Lösungsmöglichkeiten gefunden werden.

Beachten Sie, dass die Quellen auch mit -O1 oder höher übersetzt werden müssen, damit diese Option einen Effekt hat. Falls die Umgebungsvariable DEB_BUILD_OPTIONS noopt enthält, dann wird die Unterstützung von fortify aufgrund neuer Warnungen von Glibc 2.16 und neuer deaktiviert.

stackprotector

Diese Einstellung (standardmäßig aktiviert falls stackprotectorstrong nicht verwandt wird) fügt -fstack-protector --param=ssp-buffer-size=4 zu CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS und FCFLAGS hinzu. Dies fügt Sicherheitsprüfungen gegen die Überschreibung des Stapelspeichers (Stacks) hinzu. Damit werden viele mögliche Code-Einfügeangriffe zu Abbruchsituationen. Im besten Fall werden damit Code-Einfügungsangriffe zu Diensteverweigerungsangriffen oder zu keinen Problemen (abhängig von der Anwendung).

Diese Funktionalität benötigt das Linken mit Glibc (oder einem anderen Anbieter von __stack_chk_fail). Sie muss daher deaktiviert werden, wenn mit -nostdlib oder -ffreestanding oder Ähnlichem gebaut wird.

stackprotectorstrong

Diese Einstellung (standardmäßig aktiviert) fügt -fstack-protector-strong zu CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS und FCFLAGS hinzu. Dies ist eine stärkere Variante von stackprotector allerdings ohne signifikante Einbußen bei der Leistung.

Deaktivierung von stackprotector deaktiviert auch diese Einstellung.

Diese Funktionalität stellt die gleichen Anforderungen wie stackprotector und benötigt zusätzlich Gcc 4.9 oder neuer.

relro

Diese Einstellung (standardmäßig aktiviert) fügt -Wl,-z,relro zu LDFLAGS hinzu. Während des Ladens des Programms müssen mehrere ELF-Speicherabschnitte vom Binder (Linker) geschrieben werden. Diese Einstellung signalisiert dem Ladeprogramm, diese Abschnitte in nur-Lese-Zugriff zu ändern, bevor die Steuerung an das Programm übergeben wird. Insbesondere verhindert dies GOT-Überschreibeangriffe. Falls diese Option deaktiviert ist, wird auch bindnow deaktiviert.

bindnow

Diese Einstellung (standardmäßig deaktiviert) fügt -Wl,-z,now zu LDFLAGS hinzu. Während des Ladens des Programms werden alle dynamischen Symbole aufgelöst, womit das gesamte PLT nur-lesend markiert werden kann (aufgrund von relro oben). Diese Option kann nicht aktiviert werden, falls relro nicht aktiviert ist.

pie

Diese Einstellung (standardmäßig deaktiviert) fügt -fPIE zu CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS und FCFLAGS sowie -fPIE -pie zu LDFLAGS hinzu. »Position Independent Executable« (positionsunabhängige Programme) werden benötigt, um »Address Space Layout Randomization« (Bereitstellung eines zufälligen Adressbereichlayouts) auszunutzen, der von einigen Kernelversionen bereitgestellt wird. Während ASLR bereits für Datenbereiche auf dem Stapel (Stack) und Heap erzwungen werden kann (brk und mmap), müssen die Codebereiche positionsunabhängig übersetzt werden. Laufzeitbibliotheken machen dies bereits (-fPIC), so dass sie ASLR automatisch erhalten, aber Programm-.text-Regionen müssen mit PIE gebaut werden, um ASLR zu erhalten. Wenn dies passiert, sind ROP- (Return Oriented Programming) Angriffe sehr viel schwerer durchzuführen, da es keine statischen Orte mehr gibt, zu denen während eines Speicherverfälschungsangriffs hingesprungen werden könnte.

Dies ist nicht mit -fPIC kompatibel, daher muss beim Erstellen von Laufzeitbibliotheken Vorsicht angewandt werden.

Static libraries can be used by programs or other shared libraries. Depending on the flags used to compile all the objects within a static library, these libraries will be usable by different sets of objects:

none: Cannot be linked into a PIE program, nor a shared library.
-fPIE: Can be linked into any program, but not a shared library.
-fPIC: Can be linked into any program and shared library.

Unconditionally passing -fPIE, -fpie or -pie to a build-system using libtool is safe as these flags will get stripped when building shared libraries. Otherwise on projects that build both programs and shared libraries you might need to make sure that when building the shared libraries -fPIC is always passed last (so that it overrides any previous -PIE) to compilation flags such as CFLAGS, and -shared is passed last (so that it overrides any previous -pie) to linking flags such as LDFLAGS.

Zusätzlich können auf einigen Architekturen mit sehr wenigen Registern (dazu gehört aber i386 nicht mehr, seitdem in GCC >= 5 Optimierungen erfolgten) Leistungsverluste von bis zu 15% in sehr text-Segment-lastigen Anwendungsfällen auftreten, da PIE über allgemeine Register implementiert ist; in den meisten Anwendungsfällen sind dies weniger als 1%. Architekturen mit mehr allgemeinen Registern (z.B. Amd64) erfahren nicht diese Schlimmstfall-Strafe.

Reproduzierbarkeit

Die Kompilierzeit-Optionen (weiter unten beschrieben) können dazu verwandt werden, die Reproduzierbarkeit zu verbessern oder zusätzliche Warnungsmeldungen während der Übersetzung auszugeben. Sie werden für Architekturen, die diese unterstützen, standardmäßig aktiviert; die Ausnahmen sind unten angegeben.

timeless: Diese (standardmäßig aktivierte) Einstellung fügt -Wdate-time zu CPPFLAGS hinzu. Dies führt zu Warnungen, wenn die Makros __TIME__, __DATE__ und __TIMESTAMP__ verwandt werden.
fixdebugpath: This setting (disabled by default) adds -fdebug-path-map=BUILDPATH=. to CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS and FCFLAGS where BUILDPATH is set to the top-level directory of the package being built. This has the effect of removing the build path from any generated debug symbols.

UMGEBUNG

Es gibt zwei Gruppen von Umgebungsvariablen, die den gleichen Vorgang durchführen. Der erste (DEB_Schalter_Vorg) sollte niemals innerhalb von debian/rules verwandt werden. Er ist für Benutzer gedacht, die das Quellpaket mit anderen Bauschaltern erneut bauen möchten. Der zweite Satz (DEB_Schalter_MAINT_Vorg) sollte nur durch Paketbetreuer in debian/rules verwandt werden, um die entstehenden Bauschalter zu ändern.

DEB_Schalter_SET: DEB_Schalter_MAINT_SET Diese Variable kann zum Erzwingen des für Schalter zurückgegebenen Werts verwandt werden.
DEB_Schalter_STRIP: DEB_Schalter_MAINT_STRIP Diese Variable kann zum Bereitstellen einer durch Leerzeichen getrennten Liste von Optionen verwandt werden, die aus dem Satz von Schalter zurückgelieferten Schaltern entfernt werden.
DEB_Schalter_APPEND: DEB_Schalter_MAINT_APPEND Diese Variable kann zum Anhängen ergänzender Optionen zum Wert, der von Schalter zurückgegeben wird, verwandt werden.
DEB_Schalter_PREPEND: DEB_Schalter_MAINT_PREPEND Diese Variable kann zum Voranstellen ergänzender Optionen zum Wert, der von Schalter zurückgegeben wird, verwandt werden.
DEB_BUILD_OPTIONS: DEB_BUILD_MAINT_OPTIONS Diese Variablen können von Benutzern oder Betreuern zum Deaktivieren oder Aktivieren verschiedener Bereichsfunktionalitäten benutzt werden, die Bauschalter beeinflussen. Die Variable DEB_BUILD_MAINT_OPTIONS setzt jede Einstellung in den Funktionalitätsbereichen DEB_BUILD_OPTIONS außer Kraft. Lesen Sie den Abschnitt FUNKTIONALITÄTSBEREICHE für weitere Details.
DEB_VENDOR: This setting defines the current vendor. If not set, it will discover the current vendor by reading /etc/dpkg/origins/default.
DEB_BUILD_PATH: This variable sets the build path (since dpkg 1.18.8) to use in features such as fixdebugpath so that they can be controlled by the caller. This variable is currently Debian and derivatives-specific.

DATEIEN

Konfigurationsdateien

/etc/dpkg/buildflags.conf: Systemweite Konfigurationsdatei
$XDG_CONFIG_HOME/dpkg/buildflags.conf oder: $HOME/.config/dpkg/buildflags.conf Benutzer-Konfigurationsdatei

Paketierungsunterstützung

/usr/share/dpkg/buildflags.mk: Makefile-Schnipsel, das alle von dpkg-buildflags unterstützten Schalter in Variablen laden (und optional exportieren) wird. (seit Dpkg 1.16.1)

BEISPIELE

Um Bauschalter an eine Baubefehl in einer Makefile zu übergeben:

$(MAKE) $(shell dpkg-buildflags --export=cmdline)
./configure $(shell dpkg-buildflags --export=cmdline)

Um Bauschalter in einem Shell-Skript oder Shell-Fragement zu setzen, kann eval verwendet werden, um die Ausgabe zu interpretieren und die Schalter in die Umgebung zu exportieren:

eval "$(dpkg-buildflags --export=sh)" && make

Oder die Positionsparameter zu setzen, die an einen Befehl übergeben werden sollen:

eval "set -- $(dpkg-buildflags --export=cmdline)"
for dir in a b c; do (cd $dir && ./configure "$@" && make); done

Verwendung in debian/rules

Sie sollten dpkg-buildflags aufrufen oder buildflags.mk in die Datei debian/rules einbinden, um die benötigten Bauschalter, die an das Bausystem weitergegeben werden sollen, abzufragen. Beachten Sie, dass ältere Versionen von dpkg-buildpackage (vor Dpkg 1.16.1) diese Variablen automatisch exportierten. Allerdings sollten Sie sich nicht darauf verlassen, da dies den manuellen Aufruf von debian/rules nicht korrekt ermöglicht.

Für Pakete mit Autoconf-artigen Bausystemen können Sie die relevanten Optionen direkt wie oben gezeigt an Configure oder make(1) übergeben.

Für andere Bausysteme oder wenn Sie feingranularere Steuerung benötigen (welcher Schalter wo weitergegeben wird), können Sie --get verwenden. Oder Sie können stattdessen buildflags.mk einbinden, das sich um den Aufruf von dpkg-buildflags kümmert und die Bauschalter in Make-Variablen speichert.

Falls Sie alle Bauschalter in die Umgebung exportieren möchten (wo sie dann vom Baussystem eingelesen werden können):

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk

Für zusätzliche Steuerung was exportiert wird, können Sie die Variablen manuell exportieren (da keine standardmäßig exportiert werden):

include /usr/share/dpkg/buildflags.mk
export CPPFLAGS CFLAGS LDFLAGS

Und natürlich können Sie die Schalter manuell an Befehle weitergeben:

include /usr/share/dpkg/buildflags.mk
build-arch:
        $(CC) -o hello hello.c $(CPPFLAGS) $(CFLAGS) $(LDFLAGS)

ÜBERSETZUNG

Die deutsche Übersetzung wurde 2004, 2006-2016 von Helge Kreutzmann <[email protected]>, 2007 von Florian Rehnisch <[email protected]> und 2008 von Sven Joachim <[email protected]> angefertigt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 2 oder neuer für die Kopierbedingungen. Es gibt KEINE HAFTUNG.