Remarques sur la construction de logiciels

Construction de logiciels en tant qu'utilisateur non privilégié (non root)

La règle d'or de l'administration d'un système Unix est de n'utiliser vos super-pouvoirs que si nécessaire. D'où la recommandation de BLFS de construire les logiciels en tant qu'utilisateur non privilégié et de ne devenir l'utilisateur root que lors de l'installation du logiciel. On suit cette philosophie dans tous les paquets du livre. Sauf spécifications contraires, toutes les instructions devraient être exécutées en tant qu'utilisateur non privilégié. Le livre vous conseillera sur les instructions qui ont besoin des privilèges root.

Déballer le logiciel

S'il y a un fichier compressé au format .tar, on le déballe en utilisant une des commandes suivantes :

tar -xvf filename.tar.gz
tar -xvf filename.tgz
tar -xvf filename.tar.Z
tar -xvf filename.tar.bz2

Vous pouvez utiliser aussi une méthode légèrement différente :

bzcat filename.tar.bz2 | tar -xv

Enfin, vous avez parfois besoin de déballer des correctifs qui ne sont généralement pas au format .tar. La meilleure manière de faire cela est de copier le chemin du fichier dans le parent du répertoire de 'construction' puis d'exécuter une des commandes suivantes selon que le fichier est un .gz ou un .bz2 :

gunzip -v patchname.gz
bunzip2 -v patchname.bz2

Vérifier l'intégrité des fichiers en utilisant 'md5sum'

En général, pour vérifier que le fichier téléchargé est authentique et complet, de nombreux mainteneurs de paquets distribuent aussi des sommes md5 des fichiers. Pour vérifier la somme md5 des fichiers téléchargés, téléchargez à la fois le fichier et le fichier md5sum correspondant dans le même répertoire (de préférence à partir d'emplacements différents en ligne) et (en supposant que file.md5sum est le fichier md5sum téléchargé), lancez la commande suivante :

md5sum -c file.md5sum

S'il y a une erreur, elle sera signalée. Remarquez que le livre BLFS comprend les sommes md5 de tous les fichiers sources. Pour utiliser les sommes md5 fournies par BLFS, vous pouvez créer un file.md5sum (mettez les données md5sum et le nom exact du fichier téléchargé sur la même ligne d'un fichier, séparés par un espace blanc), et lancez la commande montrée ci-dessus. Sinon, lancez simplement la commande décrite ci-dessus et comparez la sortie avec les données de somme md5 inscrites dans le livre BLFS.

md5sum <name_of_downloaded_file>

Créer des fichiers journaux pendant l'installation

Pour les gros paquets, il est commode de créer des fichiers journaux plutôt que de dévisager l'écran en espérant récupérer une erreur ou un avertissement particulier. Les fichiers journaux sont aussi utiles pour déboguer et garder des enregistrements. La commande suivante vous permet de créer un journal d'installation. Remplacez <commande> par la commande que vous cherchez à exécuter.

( <command> 2>&1 | tee compile.log && exit $PIPESTATUS )

2>&1 redirige les messages d'erreur vers le même endroit que la sortie standard. La commande tee vous permet de voir la sortie en journalisant les résultats dans un fichier. Les parenthèses autour de la commande exécutent toute la commande dans un sous-shell et, enfin, la commande exit $PIPESTATUS s'assure que c'est bien le résultat de <commande> qui est retourné et pas le résultat de la commande tee.

Utilisation de processeurs multiples

Pour la plupart des systèmes modernes avec des processeurs multiples (ou cœurs) le temps de compilation pour un paquet peut être réduit en effectuant une « construction parallèle » soit en initialisant une variable d'environnement, soit en disant au programme make combien de processeurs sont disponibles. Par exemple, un Core2Duo peut supporter deux processus simultanés avec :

export MAKEFLAGS='-j2'

ou en compilant simplement avec :

make -j2

Généralement le nombre de processus ne doit pas dépasser le nombre de cœurs supportés par le CPU. Pour lister les processeurs de votre système, tapez : grep processor /proc/cpuinfo.

Dans certains cas, l'utilisation de processeurs multiples peut amener dans une sorte de « course » où le succès de la construction dépend de l'ordre des commandes lancées par le programme make. Par exemple, si un exécutable demande un fichier A et un fichier B, essayer de lier le programme avant qu'un des composants dépendants ne soit disponible aboutira à un échec. Cela arrive en général quand les développeurs n'ont pas correctement désigné tous les prérequis utiles pour accomplir une étape du Makefile.

Si cela arrive, la meilleure chose à faire est de recommencer la construction avec un seul processeur. En ajoutant « -j1 » à une commande make, cela écrasera l'initialisation similaire dans une variable d'environnement MAKEFLAGS.

Procédures de construction automatique

Il y a des fois où automatiser la construction d'un paquet peut s'avérer utile. Chacun a ses raisons de vouloir automatiser la construction, et chacun le fait par ses propres moyens. Soit en créant des Makefiles, des scripts Bash, des scripts Perl ou simplement une liste de commandes utilisées à copier-coller, sont des méthodes que vous pouvez utiliser pour automatiser la construction de paquets BLFS. Détailler et donner des exemples sur les nombreuses manières d'automatiser la construction de paquets va au-delà des objectifs de cette section. Cette section vous présentera l'utilisation de la redirection de fichiers et de la commande yes pour vous donner des idées sur la façon d'automatiser vos constructions.

Redirection de fichier pour automatiser l'entrée

Il y aura des moments, pendant votre aventure BLFS, où vous tomberez sur un paquet ayant une invite de commande vous demandant des informations. Ces informations peuvent être des détails de configuration, un chemin de répertoire ou une réponse à un accord de licence. Il peut être un challenge d'automatiser la construction de ce paquet. On vous demandera occasionnellement des informations via une série de questions. Une méthode pour automatiser ce type de scénario est de mettre les réponses désirées dans un fichier et d'utiliser la redirection pour que le programme utilise les données du fichier comme réponses aux questions.

La construction du paquet CUPS est un bon exemple de la façon de rediriger un fichier comme entrée aux invites, cela peut vous aider à automatiser la construction. Si vous lancez la suite de test, on vous demande de répondre à une série de questions concernant le type de test à exécuter et si vous avez un programme auxiliaire que le test peut utiliser. Vous pouvez créer un fichier avec vos réponses, une par ligne, et utiliser une commande ressemblant à celle indiquée ci-dessous pour automatiser l'exécution de la suite de tests :

make check < ../cups-1.1.23-testsuite_parms

Cela fait que la suite de tests utilise les réponses du fichier comme entrée pour les questions. Vous pouvez finir par faire des essais et des erreurs pour déterminer le format exact de votre fichier d'entrée pour certaines choses, mais une fois expérimenté et documenté, vous pouvez utiliser cela pour automatiser la construction du paquet.

Utiliser yes pour automatiser l'entrée

Vous n'aurez parfois besoin que de fournir une réponse ou une même réponse à de nombreuses invites. Dans ces cas-là, la commande yes fonctionne vraiment bien. On peut utiliser la commande yes pour fournir une réponse (la même) à une ou plusieurs questions. On peut l'utiliser pour simuler un simple appui sur la touche Entrée, l'entrée de la touche Y ou l'entrée d'une chaîne de texte. La manière la plus facile de montrer son utilisation est peut-être de prendre un exemple.

Créez tout d'abord un petit script Bash en entrant les commandes suivantes :

cat > blfs-yes-test1 << "EOF"
#!/bin/bash

echo -n -e "\n\nPlease type something (or nothing) and press Enter ---> "

read A_STRING

if test "$A_STRING" = ""; then A_STRING="Just the Enter key was pressed"
else A_STRING="You entered '$A_STRING'"
fi

echo -e "\n\n$A_STRING\n\n"
EOF
chmod 755 blfs-yes-test1

Maintenant, lancez le script en lançant ./blfs-yes-test1 depuis la ligne de commande. Il attendra une réponse, qui peut être n'importe quoi (ou rien) suivi de la touche Entrée. Après avoir entré quelque chose, le résultat sera affiché à l'écran. Utilisez maintenant la commande yes pour automatiser l'entrée d'une réponse :

yes | ./blfs-yes-test1

Remarquez que la redirection (le piping) de yes en lui-même vers le script aboutit à ce que y est passé au script. Essayez-la maintenant avec une chaîne de texte :

yes 'This is some text' | ./blfs-yes-test1

La chaîne exacte était utilisée comme réponse au script. Enfin, essayez-la en utilisant une chaîne vide (null) :

yes '' | ./blfs-yes-test1

Remarquez que cela aboutit à ne passer au script que l'appui sur la touche Entrée. C'est utile parfois quand la réponse par défaut à l'invite est suffisante. Cette syntaxe est utilisée dans les instructions de Net-tools pour accepter tous les réglages par défaut à toutes les invites lors de l'étape de configuration. Vous pouvez maintenant supprimer le script de test si vous le désirez.

Redirection de fichiers pour automatiser la sortie

Pour automatiser la construction de certains paquets, surtout ceux qui vous demandent de lire un accord de licence page après page, il faut utiliser une méthode qui évite de devoir appuyer sur une touche pour afficher chaque page. On peut utiliser la redirection de sortie vers un fichier dans ce cas-là pour vous aider à automatiser. La section précédente de cette page a visé à créer des fichiers journaux de la sortie de la construction. La méthode de redirection qui y est décrite utilisait la commande tee pour rediriger la sortie tout en affichant aussi la sortie à l'écran. Ici on ne verra la sortie que dans un fichier.

De nouveau, la manière la plus facile de montrer la technique est de présenter un exemple. Lancez d'abord la commande :

ls -l /usr/bin | more

Bien entendu, vous devrez voir la sortie page par page car on a utilisé le filtre more. Essayez maintenant la même commande, mais en redirigeant cette fois la sortie vers un fichier. Le fichier spécial /dev/null peut être utilisé à la place du fichier indiqué, mais vous n'aurez pas de fichier journal à examiner :

ls -l /usr/bin | more > redirect_test.log 2>&1

Remarquez que cette fois, la commande est immédiatement revenue à l'invite du shell sans devoir parcourir la sortie page par page. Vous pouvez supprimer maintenant le fichier journal.

Le dernier exemple utilisera la commande yes associée à la redirection de sortie pour éviter de naviguer page par page dans la sortie, puis de fournir un y à l'invite. Cette technique peut être utilisée dans les cas où vous devriez, sans elle, naviguer page par page dans la sortie d'un fichier (tel qu'un accord de licence), puis répondre à la question « Acceptez-vous ce qui précède ? ». Pour cet exemple, on a besoin d'un autre petit script Bash :

cat > blfs-yes-test2 << "EOF"
#!/bin/bash

ls -l /usr/bin | more

echo -n -e "\n\nDid you enjoy reading this? (y,n) "

read A_STRING

if test "$A_STRING" = "y"; then A_STRING="You entered the 'y' key"
else A_STRING="You did NOT enter the 'y' key"
fi

echo -e "\n\n$A_STRING\n\n"
EOF
chmod 755 blfs-yes-test2

On peut utiliser ce script pour simuler un programme qui demande que vous lisiez un accord de licence et que vous acceptiez le contrat avant que le programme n'installe quoique ce soit. Lancez d'abord le script sans techniques d'automatisation en exécutant ./blfs-yes-test2.

Maintenant lancez la commande suivante qui utilise les techniques d'automatisation, rendant l'utilisation convenable dans un script de construction automatisé :

yes | ./blfs-yes-test2 > blfs-yes-test2.log 2>&1

Si vous le désirez, lancez tail blfs-yes-test2.log pour voir la fin de la sortie paginée et la confirmation que y a été passé au script. Une fois que cela marche comme cela devrait, vous pouvez supprimer le script et le fichier journal.

Enfin, gardez à l'esprit qu'il y a de nombreux moyens d'automatiser ou de scripter les commandes de construction. Il n'y a pas « une seule » manière de procéder. Votre imagination est la seule limite.

Dépendances

Pour chaque paquet décrit, BLFS liste les dépendances connues. Elles sont listées sous plusieurs en-têtes, dont la signification est la suivante :

Utilisation de paquets sources plus récents

Occasionnellement, dans le livre, vous pourrez être dans la situation ou un paquet ne se construit pas ou ne fonctionne pas correctement. Bien que les éditeurs tentent de faire en sorte que chaque paquet dans le livre se construise et fonctionne correctement, parfois un paquet a été oublié ou n'a pas été testé avec cette version particulière de BLFS.

Si vous découvrez un paquet qui ne se construit pas ou ne fonctionne pas correctement, vous pouvez regarder s'il s'agit de la version la plus récente du paquet. Typiquement, cela signifie que vous irez sur le site web du mainteneur et téléchargerez l'archive la plus récente et tenterez de construire le paquet. Si vous ne pouvez pas déterminer le site web du mainteneur en regardant l'URL de chargement, utilisez Google et cherchez le nom du paquet. Par exemple, dans la barre de recherche de Google tapez: 'nom_du_paquet download' (sans les guillemets) ou quelque chose de similaire. Parfois en tapant : 'nom_du_paquet home page' vous trouverez le site web du mainteneur.

Nettoyage une fois de plus

Dans LFS, le nettoyage des symboles de déboguage a été discuté de nombreuses fois. Pour la construction des paquets BLFS, il n'y a généralement pas d'instructions qui discute de nouveau du nettoyage. Ce n'est probablement pas une bonne idée de nettoyer un exécutable ou une bibliothèque tant qu'ils sont utilisés, alors sortir des environnements de fenêtrage est une bonne idée. Ensuite vous pouvez faire :

find /{,usr/}{bin,lib,sbin} \
    -type f \( -name \*.so* -a ! -name \*dbg \) \
    -exec strip --strip-unneeded {} \;

Si vous installez des programmes dans d'autres répertoires tels que /opt ou /usr/local, vous pouvez vouloir nettoyer les fichiers ici aussi.

Pour plus d'information sur le nettoyage, regardez http://www.technovelty.org/linux/stripping-shared-libraries.html.

Travailler avec différents systèmes de construction

Il y a maintenant trois systèmes de construction différents utilisés régulièrement pour convertir du code source C ou C++ en un programme compilé ou en une bibliothèque et leur fonctionnement (en particulier, comment trouver les options disponibles et leurs valeurs par défaut) est différent. Il peut être plus facile de comprendre les problèmes causés par certains choix (typiquement une exécution lente ou l'utilisation (ou l'omission) inattendue des optimisations) en commençant par les variable d'environnement CFLAGS et CXXFLAGS. Certains programmes utilisent aussi rust.

La plupart des lecteurs de LFS et de BLFS connaissent probablement déjà les bases de l'utilisation de CFLAGS et CXXFLAGS pour altérer la compilation d'un programme. Typiquement, certaines formes d'optimisations sont utilisés par les développeurs en amont (-O2 ou -O3), parfois avec la création de symboles de débogage (-g) par défaut.

S'il y a des drapeaux contradictoires (p. ex. plusieurs valeurs différentes de -O), la dernière valeur sera utilisée. Parfois les drapeaux spécifiés dans les variables d'environnement sont insérés avant les valeurs en dur dans le Makefile, ce qui signifie qu'ils sont ignorés. Par exemple, si un utilisateur spécifie « -O2 » et qu'il est suivi de « -O3 », la construction utilisera « -O3 ».

On peut passer divers autres drapeaux dans CFLAGS et CXXFLAGS, comme pour forcer la compilation pour une microarchitecture spécifique (p. ex. -march=amdfam10, -march=native) ou pour spécifier un standard C ou C++ particulier (-std=c++17 par exemple). Mais ce qui commence à apparaître, c'est l'inclusion par les développeurs d'assertions de débogage dans leur code qui sont généralement désactivés dans les versions publiées avec -DNDEBUG. Plus spécifiquement, si Mesa-20.1.5 est construit avec ces assertions, certaines activités comme le chargement de niveaux dans les jeux peuvent prendre très longtemps, même sur des cartes vidéo haut de gamme.

Autotools avec Make

Cette combinaison est souvent décrite comme « CMMI » (configure, make, make install) et est utilisée ici pour couvrir aussi certains paquets dont le script configure n'a pas été généré par les autotools.

Parfois lancer ./configure --help affichera les options utiles des paramètres qui peuvent être utilisés. D'autres fois, après avoir regardé la sortie de configure vous pourriez avoir besoin de regarder les détails du script pour comprendre ce qu'il cherchait vraiment.

De nombreux scripts configure récupéreront les CFLAGS et CXXFLAGS de l'environnement, mais les paquets CMMI varient dans la manière dont ils seront insérés avec les drapeaux qui seraient sinon utilisés (au choix : ignorés, utilisés à la place de la suggestion des programmeurs, utilisés avant la suggestion des programmeurs ou utilisés après la suggestion des programmeurs).

Dans la plupart des paquets CMMI, « make » listera les commande lancées, séparées par des avertissements éventuels. Mais certains paquets essayent d'être « silencieux » et ne montrent que les fichiers qu'ils compilent ou dont ils éditent les liens au lieu de montrer la ligne de commande. Si vous devez inspecter la commande, soit à cause d'une erreur, ou juste pour voir les options et les drapeaux utilisés, ajouter « V=1 » à l'invocation make peut aider.

CMake

CMake fonctionne de manière différente, et il a deux moteurs qui peuvent être utilisés sur BLFS : « make » et « ninja ». Le moteur par défaut est make, mais ninja est plus rapide sur les paquets plus gros avec plusieurs processeurs. Pour utiliser ninja, spécifiez « -G Ninja » dans la commande cmake. Cependant, certains paquets peuvent avoir des erreurs fatales dans leurs fichiers ninja tout en pouvant être construits sans problème avec les Makefile Unix par défaut.

La partie la plus dure de l'utilisation de CMake est de connaître les options que vous voudrez spécifier. La seule manière de récupérer une liste de ce que le paquet connait est de lancer cmake -LAH et de regarder la sortie pour cette configuration par défaut.

Peut-être que la chose la plus importante à propos de CMake est qu'il a plusieurs valeurs de CMAKE_BUILD_TYPE, et qu'elles affectent les drapeaux. La valeur par défaut est vide et aucun drapeau n'est généré. Les CFLAGS et CXXFLAGS dans l'environnement seront utilisés. Si le programmeur a codé des assertions de débogage, elles seront activées à moins que vous n'utilisiez -DNDEBUG. Les valeurs CMAKE_BUILD_TYPE suivantes généreront les drapeaux associés, et ils seront ajoutés après les drapeaux dans l'environnement et prennent donc le pas dessus.

CMake essaye de produire des constructions silencieuses. Pour voir les détails des commandes lancées, utilisez « make VERBOSE=1 » ou « ninja -v ».

Meson

Meson ressemble un peu à CMake, mais avec beaucoup de différences. Pour trouver les détails des définitions que vous pourriez avoir besoin de modifier vous pouvez regarder dans meson_options.txt qui est généralement dans le répertoire de plus haut niveau.

Si vous avez déjà configuré le paquet en lançant meson et que vous souhaitez maintenant changer un ou plusieurs paramètres, vous pouvez soit supprimer le répertoire de construction, le recréer et utiliser les options modifiées, soit lancer meson configure dans le répertoire de construction, p. ex. pour ajouter une option :

meson configure -D<some_option>=true

Si vous faîtes cela, le fichier meson-private/cmd_line.txt contiendra les dernières commandes qui ont été utilisées.

Meson fournit les valeurs buildtype suivantes, et les drapeaux qu'elles activent viennent après les drapeaux fournis dans l'environnement et prennent donc le pas.

Bien que le type « release » soit décrit comme activant -DNDEBUG et que toutes les constructions CMake en Release le passent, cela n'a été observé jusque là (sur les constructions verbeuses) que pour Mesa-20.1.5. Cela suggère qu'il ne serait utilisé que s'il y a des assertions de débogage.

Le drapeau -DNDEBUG peut aussi être fournit en passant -Db_ndebug=true.

Pour voir les détails des commandes qui sont lancés dans un paquet qui utilise meson, utilisez « ninja -v ».

Rustc et Cargo

La plupart des programmes rustc publiés sont fournis dans des archives (ou « crates ») qui demanderont à un serveur de vérifier les versions actuelles des dépendances et les téléchargera au besoin. Ces paquet sont construits avec cargo --release. En théorie, on peut manipuler les RUSTFLAGS pour changer le niveau d'optimisation (par défaut 3, come -O3, p. ex. -Copt-level=3) ou pour forcer la construction pour la machine sur laquelle il est compilé, avec -Ctarget-cpu=native mais en pratique cela ne semble pas faire de réelle différence.

Si vous trouvez un programme rustc intéressant qui n'est fournit que sous forme de sources sans paquet, vous devriez au moins spécifier RUSTFLAGS=-Copt-level=2 sans quoi rustc effectuera une compilation sans optimisation et et avec les informations de débogage et le résultat sera beaucoup plus lent.

Les développeurs de rust ont l'air de supposer que tout le monde compile sur une machine dédiées aux constructions de production, donc par défaut tous les CPU sont utilisés. Cela peut souvent être changé, soit en exportant CARGO_BUILD_JOBS=<N> ou en passant --jobs <N> à cargo. Pour compiler rustc lui-même, spécifiez --jobs <N> lors de l'invocation de x.py (avec la variable d'environnement CARGO_BUILD_JOBS, ce qui ressemble à une approche « ceinture et bretelle » mais a l'air nécessaire). L'exception est le lancement des tests à la construction de rustc, où certains d'entre eux utiliseront tout de même tous les CPU en ligne, aux moins à partir de rustc-1.42.0.

Optimisation de la construction

De nombreuses personnes préfèrent optimiser la compilation à leur goût, en fournissant CFLAGS ou CXXFLAGS. Vous trouverez une introduction aux options disponibles avec gcc et g++ sur https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html et dans info gcc.

Certains paquet utilisent par défaut « -O2 -g », d'autres « -O3 -g » et si les CFLAGS ou CXXFLAGS sont fournis ils peuvent être ajoutés aux valeurs par défaut du paquet, remplacer les valeurs par défaut ou même être ignorés. Il y a des détails sur les dernières versions (en avril 2019) de certains paquets graphiques sur http://www.linuxfromscratch.org/~ken/tuning/ — en particulier, README.txt, tuning-1-packages-and-notes.txt et tuning-notes-2B.txt. Ce dont il faut se souvenir, c'est que si vous voulez essayer certains des drapeaux les plus intéressants vous devriez forcer les constructions à être plus verbeuses pour confirmer qu'elles sont utilisées.

Clairement, si vous optimisez votre propre programme vous pouvez passer du temps à effectuer des mesures et peut-être recoder certaines parties plutôt lentes. Mais pour construire un système complet cette approche est impossible. En général, -O3 produit des programmes plus rapides que -O2. Spécifier -march=native est aussi bénéfique, mais cela signifie que vous ne pouvez pas utiliser les binaires sur une machine incompatible — cela s'applique aussi à des machines plus récentes, pas seulement à des machines plus vieilles. Par exemple les programmes compilés pour « amdfam10 » peuvent tourner sur les vieux Phenoms, Kaveris et Ryzens ; mais les programmes compilés pour un Kaveri ne tourneront pas sur un Ryzen parce que certains opcodes ne sont pas présents. De manière identique, si vous construisez pour un Haswell tout ne tournera pas sur un SandyBridge.

Il y a aussi diverses autres options que certains pensent bénéfiques. Au pire, vous devrez recompiler et tester, pour découvrir que pour votre utilisation ces options font rien de spécial.

Si vous construisez des modules Perl ou Python, ou des paquets Qt qui utilisent qmake, en général les CFLAGS et CXXFLAGS utilisés sont ceux utilisés pour construire ces paquets « parents ».

Options pour durcir la construction

Même sur un système de bureau, il y a des vulnérabilités exploitables. Pour beaucoup, l'attaque vient de javascript dans un navigateur. Souvent, une série de vulnérabilités sont utilisées pour récupérer un accès aux données (ou parfois pour powner, c.-à-d. cracker la machine et installer des rootkits). La plupart des distributions commerciales appliqueront diverses mesures de durcissement.

Pour les options de durcissement qui sont raisonnablement peu coûteuses, on en parle un peu dans le lien sur les expériences de peaufinage précédent (parfois une ou plus de ces options peuvent être inappropriées pour un paquet). Ces options sont -D_FORTIFY_SOURCE=2, -fstack-protector=strong et (pour C++) -D_GLIBCXX_ASSERTIONS. Sur les machines modernes elles ne devraient avoir qu'un très faible impact sur la vitesse des programmes et souvent ne seront même pas perceptibles.

Par le passé, il existait un Hardened LFS (LFS durci) où gcc (une version beaucoup plus vieille) était forcé à utiliser le durcissement (avec des options pour les désactiver au cas par cas). Ce dont on parle ici est différent — vous devrez déjà vous assurer que le paquet utilise bien vos options supplémentaires et qu'il ne les écrase pas.

Les distros principales utilisent bien plus, comme RELRO (Relocation Read Only) et parfois -fstack-clash-protection. Vous pouvez aussi rencontrer les « retpolines en espace utilisateur » (-mindirect-branch=thunk etc) qui sont équivalents aux atténuations de spectre appliqués au noyau linux fin 2018. Les atténuations du noyau ont causés de nombreuses plaintes à propos d'une perte de performances donc si vous avez un serveur en production vous devriez peut-être tester ça ainsi que d'autres options disponibles, pour voir si les performances sont toujours satisfaisantes.

Tandis que gcc a de nombreuses options de durcissement, la force de clang/LLVM se trouve ailleurs. Certaines options fournies par gcc sont dite moins efficaces dans clang/LLVM et d'autres ne sont simplement pas disponibles.