dpkg-buildflags(1) dpkg suite dpkg-buildflags(1)
BEZEICHNUNG
dpkg-buildflags - 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 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.
BEFEHLE
--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.
UNTERSTÜTZTE SCHALTER
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).
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 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
future (Zukunft)
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.
qa (QS)
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.
optimize (Optimierung)
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.
sanitize (Bereinigung)
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.
hardening (Härtung)
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.
reproducible (Reproduzierbarkeit)
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.
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
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).
DATEIEN
Konfigurationsdateien
/etc/dpkg/buildflags.conf
Systemweite Konfigurationsdatei
$XDG_CONFIG_HOME/dpkg/buildflags.conf oder
$HOME/.config/dpkg/buildflags.conf
Benutzerkonfigurationsdatei
Paketierungsunterstützung
/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)
BEISPIELE
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
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 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)
ÜBERSETZUNG
Die deutsche Übersetzung wurde 2004, 2006-2023 von Helge Kreutzmann
<debian@helgefjell.de>, 2007 von Florian Rehnisch <eixman@gmx.de> und
2008 von Sven Joachim <svenjoac@gmx.de> 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.
1.21.22 2023-05-11 dpkg-buildflags(1)
Generated by dwww version 1.15 on Sat Jun 29 01:34:26 CEST 2024.