dpkg-buildflags - liefert Bauschalter zum Einsatz beim Paketbau
dpkg-buildflags [
Option …] [
Befehl]
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 vier 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 dem 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
dem vorangestellten Wert angehängt, falls der derzeitige Wert nicht
leer ist.
Die Konfigurationsdateien können Kommentare in Zeilen enthalten, die mit
einer Raute (#) beginnen. Leere Zeilen werden auch ignoriert.
- --dump
- Gibt auf der Standardausgabe alle Kompilierschalter und
ihre Werte aus. Es wird ein Schalter pro Zeile ausgegeben, wobei die Werte
durch ein Gleichheitszeichen („
Schalter=Werte“) abgetrennt werden. Dies ist die
Standardaktion.
- --list
- Gibt die Liste der vom aktuellen Lieferanten
unterstützten Schalter (einen pro Zeile) aus. Lesen Sie den
Abschnitt UNTERSTÜTZTE SCHALTER für weitere
Informationen über sie.
- --status
- Zeigt alle Informationen an, 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 ausgegeben.
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
- Gibt auf der Standardausgabe Befehle aus, 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.
-
configure (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
Make-Steuerdateifragment 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
- Alle Informationen anzeigen, die zur Erklärung des
Verhaltens des Programms hilfreich sein könnten: aktueller
Lieferant, relevante Umgebungsvariablen, Funktionalitätsbereiche,
Zustand der Funktionsschalter, ob eine Funktionalität als
eingebaute Vorgabe durch den Compiler behandelt wird (seit Dpkg 1.21.14)
und die Compiler-Schalter mit ihrem Ursprung (seit Dpkg 1.19.0).
Zum Beispiel:
Vendor: Debian
Environment:
DEB_CFLAGS_SET=-O0 -Wall
Area: qa
Features:
bug=no
canary=no
Builtins:
Area: hardening
Features:
pie=no
Builtins:
pie=yes
Area: reproducible
Features:
timeless=no
Builtins:
Flag: CFLAGS
Value: -O0 -Wall
Origin: env
Flag: CPPFLAGS
Value: -D_FORTIFY_SOURCE=2
Origin: vendor
-
--query-features Bereich
- Gibt die Funktionalitäten, die für den
übergebenen Bereich aktiviert sind, aus (seit Dpkg 1.16.2). Falls
die Funktionalität als eingebaute Vorgabe durch den Compiler
gehandhabt wird (selbst wenn nur für einige Architekturen), dann
wird das Feld Builtin ausgegeben (seit Dpkg 1.21.14). Die einzigen
unter Debian und abgeleiteten Distributionen derzeit erkannten Bereiche
sind future, 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.
Die Ausgabe ist im RFC822-Format, mit einem Abschnitt pro
Funktionalität. Beispiel:
Feature: pie
Enabled: yes
Builtin: yes
Feature: stackprotector
Enabled: yes
- --help
- Zeigt einen Hinweis zum Aufruf und beendet das
Programm.
- --version
- Gibt die Version aus und beendet das Programm.
- ASFLAGS
- Optionen für den Assembler. Standardwert: leer. Seit
Dpkg 1.21.0.
- 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.
- DFLAGS
- Optionen für den D-Compiler (ldc oder gdc). Seit
Dpkg 1.20.6.
- 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).
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 deaktivieren. Um daher alles im Bereich
hardening zu deaktivieren und nur „format“ und
„fortify“ zu aktiveren, kann Folgendes eingesetzt werden:
export DEB_BUILD_MAINT_OPTIONS=hardening=-all,+format,+fortify
Mehrere Optionen zur Kompilierung (Details weiter unten) können verwandt
werden, um Funktionen zu aktivieren, die standardmäßig aktiviert
sein sollten, dies aber aus
Rückwärtskompatibilitätsgründen nicht sein
können.
- lfs
- Diese Einstellung (standardmäßig deaktiviert)
aktiviert die Unterstützung für große Dateien auf
32-Bit-Architekturen, bei denen ihre ABI diese Unterstützung nicht
standardmäßig aktiviert, indem -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 zu CPPFLAGS hinzugefügt
wird.
Mehrere Optionen zur Kompilierung (Details weiter unten) können verwandt
werden, um 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-Zufallsbarrieren-Optionen zu den Bauschaltern hinzu, so
dass die Bauprotokolle überprüft werden können, wie
die Bauschalter weitergereicht werden. 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.
Mehrere Optionen zur Kompilierung (Details weiter unten) können verwandt
werden, um bei der Optimierung des entstehenden Programms zu helfen (seit Dpkg
1.21.0).
Hinweis: durch Aktivieren
aller dieser Optionen kann es
zu nicht reproduzierbaren Programmartefakten kommen.
- lto
- Diese Einstellung (seit Dpkg 1.21.0;
standardmäßig deaktiviert) aktiviert Link Time Optimization
(Optimierung zum Link-Zeitpunkt), indem -flto=auto
-ffat-lto-objects zu CFLAGS, CXXFLAGS, OBJCFLAGS,
OBJCXXFLAGS, GCJFLAGS, FFLAGS, FCFLAGS und
LDFLAGS hinzugefügt wird.
Mehrere Kompilierzeit-Optionen (nachfolgend 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.
Hinweis: Diese Optionen
sollten
nicht beim Bauen im Produktivbetrieb benutzt werden, da sie die
Zuverlässigkeit von spezifikationsgetreuem Code, die Sicherheit oder
sogar die Funktionalität reduzieren bzw. negativ beeinflussen
können.
- 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.
Mehrere Kompilierzeit-Optionen (nachfolgend 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 erhalten Sie Warnungen bei inkorrekter Verwendung von
Formatzeichenketten. Es wird zu einem Fehler führen, wenn
Formatfunktionen deart verwandt werden, dass daraus ein mögliches
Sicherheitsproblem werden könnte. Derzeit warnt dies bei Aufrufen
von 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 nicht
vertrauenswü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 (seit Dpkg 1.18.23 ohne globale Vorgabe,
da sie jetzt standardmäßig durch GCC auf den
Debian-Architekturen Amd64, Arm64, Armel, Armhf, Hurd-i386, I386,
Kfreebsd-amd64, Kfreebsd-i386, Mips, Mipsel, Mips64el, Powerpc, PPC64,
PPC64el, Riscv64, S390x, Sparc und Sparc64 aktiviert ist) fügt,
falls benötigt, die benötigten Optionen, um PIE zu
aktivieren oder zu deaktivieren, über GCC-Spezifikationsdateien
hinzu, abhängig davon, ob GCC auf diesen Architekturen die Schalter
selbst einspeist oder nicht. Wenn die Einstellung aktiviert ist und GCC
den Schalter einspeist, fügt dies nichts hinzu. Wenn die
Einstellung aktiviert ist und GCC den Schalter nicht einspeist, dann
fügt es -fPIE (mittels
/usr/share/dpkg/pie-compiler.specs) zu CFLAGS,
CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS,
FFLAGS und FCFLAGS und -fPIE -pie (mittels
/usr/share/dpkg/pie-link.specs) zu LDFLAGS hinzu. Wenn die
Einstellung deaktiviert ist und GCC den Schalter einspeist, dann
fügt es -fno-PIE (mittels
/usr/share/dpkg/no-pie-compile.specs) zu CFLAGS,
CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS,
FFLAGS und FCFLAGS und -fno-PIE -no-pie (mittels
/usr/share/dpkg/no-pie-link.specs) zu LDFLAGS hinzu.
„Position Independent Executable“ (positionsunabhängige
Programme) (PIE) ist benötigt, um „Address Space Layout
Randomization“ (Bereitstellung eines zufälligen
Adressbereichlayouts) (ASLR) 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
als 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.
PIE ist nicht zu -fPIC kompatibel, daher müssen Sie beim Bau
von Laufzeitbibliotheksobjekten im Allgemeinen Vorsicht walten lassen. Da
aber der ausgegebene PIE-Schalter mittels GCC-Spezifikationsdateien
hinzugefügt wird, sollte es immer sicher sein, sie bedingungslos zu
setzen, unabhängig von dem Objekttyp, der übersetzt oder
gelinkt wird.
Statische Bibliotheken können von jedem Programm und anderen
statischen Bibliotheken benutzt werden. Abhängig von den zum
Kompilieren aller Objekte innerhalb einer statischen Bibliothek verwandten
Schaltern können diese Bibliotheken von verschiedenen Gruppen von
Objekten verwandt werden:
- keine
- Kann weder in ein PIE-Programm noch in eine
Laufzeitbibliothek gelinkt werden.
- -fPIE
- Kann in jedes Programm, aber nicht in eine
Laufzeitbibliothek gelinkt werden (empfohlen).
- -fPIC
- Kann in jedes Programm und jede Laufzeitbibliothek gelinkt
werden.
Falls es notwendig ist, diese Schalter manuell zu setzen und die
GCC-Spezifikations-Hinzufügung zu umgehen, müssen mehrere Dinge
beachtet werden. Die bedingungslose und explizite Übergabe von
-fPIE,
-fpie oder
-pie an das Bausystem mit Libtool ist
sicher, da diese Schalter entfernt werden, wenn Laufzeit-Bibliotheken gebaut
werden. Andernfalls könnte es bei Projekten, die sowohl Programme wie
auch Laufzeit-Bibliotheken bauen, notwendig sein, dass Sie beim Bau der
Laufzeit-Bibliotheken sicherstellen, dass
-fPIC immer als Letztes an
die Kompilierungsschalter wie
CFLAGS übergeben wird (so dass es
jedes frühere
-PIE außer Kraft setzen kann) und
-shared als Letztes an Link-Schalter wie
LDFLAGS
übergeben wird (so dass es jedes frühere
-pie
außer Kraft setzen kann).
Hinweis: Das sollte mit der
Vorgabe-GCC-Spezifikationsmaschinerie nicht notwendig sein.
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.
Die Kompilierzeit-Optionen (nachfolgend 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.
- fixfilepath
- Diese Einstellung (standardmäßig aktiviert)
fügt -ffile-prefix-map=BUILDPATH=. zu
CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS,
GCJFLAGS, FFLAGS und FCFLAGS hinzu, wobei
BUILDPATH auf das oberste Verzeichnis des bauenden Pakets gesetzt
wird. Dies führt dazu, dass der Baupfad aus allen erstellten
Dateien entfernt wird.
Falls sowohl fixdebugpath als auch fixfilepath gesetzt sind,
hat diese Option Vorrang, da sie eine Obermenge erster ist.
- fixdebugpath
- Diese Einstellung (standardmäßig aktiviert)
fügt -fdebug-prefix-map=BUILDPATH=. zu
CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS,
GCJFLAGS, FFLAGS und FCFLAGS hinzu, wobei
BUILDPATH auf das oberste Verzeichnis des bauenden Pakets gesetzt
wird. Dies führt dazu, dass der Baupfad aus allen erstellten
Debug-Symbolen entfernt wird.
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
- Diese Einstellung definiert den aktuellen Lieferanten.
Falls nicht gesetzt, wird er aus /etc/dpkg/origins/default
ermittelt.
- DEB_BUILD_PATH
- Diese Variable setzt den Baupfad (seit Dpkg 1.18.8), der in
Funktionalitäten wie fixdebugpath verwandt wird, so dass sie
durch den Aufrufenden gesteuert werden können. Diese Variable ist
derzeit spezifisch für Debian und Derivative.
- DPKG_COLORS
- Setzt den Farbmodus (seit Dpkg 1.18.5). Die derzeit
unterstützten Werte sind: auto (Vorgabe), always und
never.
- DPKG_NLS
- Falls dies gesetzt ist, wird es zur Entscheidung, ob Native
Language Support, auch als Unterstützung für
Internationalisierung (oder i18n) bekannt, aktiviert wird (seit Dpkg
1.19.0). Die akzeptierten Werte sind: 0 und 1
(Vorgabe).
- /etc/dpkg/buildflags.conf
- Systemweite Konfigurationsdatei
-
$XDG_CONFIG_HOME/dpkg/buildflags.conf
oder
-
$HOME/.config/dpkg/buildflags.conf
- Benutzerkonfigurationsdatei
- /usr/share/dpkg/buildflags.mk
- Make-Steuerdateischnipsel, das alle von
dpkg-buildflags unterstützten Schalter in Variablen laden
(und optional exportieren) wird. (seit Dpkg 1.16.1)
Um Bauschalter an einen Baubefehl in einer Make-Steuerdatei 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
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 feiner granulierte 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 Bausystem 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)
Die deutsche Übersetzung wurde 2004, 2006-2023 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.