Problème de compilation avec gcc 9.2 (debian/testing)
Bonjour à tous, Depuis la mise à jour de mon poste de travail (debian/testing), j'ai un problème de compilation assez surprenant que je n'arrive à résoudre. Sources : http://www.rpl2.fr/download/rpl-4.1.31-daily-20191027.tar.bz2 Procédure de compilation : ./autogen.sh cd .. mkdir build cd build ../rpl/configure --enable-native --enable-rplcas Et attendre l'erreur : g++ -g -O2 -mtune=native -march=native -O2 -malign-double -Wall -funsigned-char -fpermissive -fno-strict-aliasing -DGIAC_GENERIC_CONSTANTS -pthread -o icas icas.o /export/home/bertrand/gopher/rpl2/build-amd64/rplcas/giac-1.5.0/src/.libs/libgiac.a /import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libpari.a /import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/ntl.a /import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libcocoa.a /import/home/bertrand/gopher/rpl2/build-amd64/tools/gsl-2.6/.libs/libgsl.a /import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libgmp.a /import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libmpfr.a /import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libmpfi.a ./.libs/libxcas.a /export/home/bertrand/gopher/rpl2/build-amd64/rplcas/giac-1.5.0/src/.libs/libgiac.a -lrt -lpthread /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so -lsamplerate -llapack -lblas -lgfortran -ldl -lpng16 -lm -pthread /usr/bin/ld: /import/home/bertrand/gopher/rpl2/build-amd64/rplcas/lib/libmpfr.a(get_z_exp.o): référence au symbole non défini « __gmpz_realloc2 » /usr/bin/ld : /usr/lib/x86_64-linux-gnu/libgmp.so.10 : erreur lors de l'ajout de symboles : DSO manquant dans la ligne de commande collect2: error: ld returned 1 exit status Pour un certain nombre de raisons, les bibliothèques sont compilées statiquement (ça permet de ne pas segfaulter lorsque l'on charge des modules externes). L'erreur varie en fonction de l'ordre des bibliothèques. Avec gcc 8, ça compile sans problème. mpfr est configuré comme suit : ../../../rpl/rplcas/mpfr-4.0.2/configure --with-gmp=/import/home/bertrand/gopher/rpl2/build-amd64/rplcas --disable-shared --enable-static --prefix=/import/home/bertrand/gopher/rpl2/build-amd64/rplcas et le script configure trouve bien les en-têtes et la version statique de libgmp. Naturellement, le symbole non trouvé est bien présent dans la bibliothèque libgmp.a : rayleigh:[~/gopher/rpl2/build-amd64/rplcas/lib] > nm -a libgmp.a | grep __gmpz_realloc2 T __gmpz_realloc2 J'avoue que je ne sais plus où chercher. Toute idée est la bienvenue. Bien cordialement, JKB
erreur kde5 et bullseye
bonjour,
depuis ma dernière mise à jour de bullseye KDE est passé en langue anglaise.
lorsque je lance systemsettings5 j'ai un certain nombre d'erreurs et la
page [Language] de l'onglet [Regional Setting] est vide
voici ce que le terminal me dit :
:~$ systemsettings5
QCoreApplication::arguments: Please instantiate the QApplication object
first
WARNING: viewBackgroundColor is deprecated, use backgroundColor with
colorSet: Theme.View instead
WARNING: viewBackgroundColor is deprecated, use backgroundColor with
colorSet: Theme.View instead
kf5.kactivity.stat: [Error at ResultSetPrivate::initQuery]:
QSqlError("1", "Unable to execute statement", "no such column:
rl.initiatingAgent")
kf5.kactivity.stat: [Error at ResultSetPrivate::initQuery]:
QSqlError("1", "Unable to execute statement", "no such column:
rl.initiatingAgent")
org.kde.kcoreaddons: Error loading plugin "kcm_translations" "The shared
library was not found."
Plugin search paths are ("/usr/lib/x86_64-linux-gnu/qt5/plugins",
"/usr/bin")
The environment variable QT_PLUGIN_PATH might be not correctly set
"file:///usr/share/kpackage/kcms/kcm_translations/contents/ui/main.qml"
"Error loading QML file.\n180: Type Kirigami.SwipeListItem
unavailable\n25: Type T.SwipeListItem unavailable\n264: Syntax error\n"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/PageRow.qml:214:
TypeError: Cannot read property 'createObject' of null
est-ce une erreur connue ?
avez-vous une idée pour remédier à cela ?
merci
Re: /boot et lvm
Le 25/10/2019 à 09:21, Patg a écrit : Les problématiques, il s'agit de celles qui existaient déjà avec GRUB 1 au sujet de lvm, et que je pensais à tord résolu dans la version 2, que tu énonces "ses inconvénients et notamment une complexité supplémentaire. Je ne comprends pas trop ce que tu veux dire. GRUB 1 ne supportait pas du tout LVM. GRUB 2 comble cette carence (au moins pour les volumes logiques simples) mais il est évident qu'il ne change rien à la complexité intrinsèque de LVM (qui est le prix de sa souplesse et de ses fonctionnalités). En cas de problème qui empêcherait GRUB d'accéder aux volumes logiques, tout démarrage est impossible" Je pense notamment suite à un plantage du serveur ou autre... Et qui empêcherait GRUB d'avoir la main sur le boot en lvm. Il ne faut pas exagérer la gravité de cet inconvénient. Il reste possible de démarrer un système de dépannage depuis un support amovible. Je n'ai pas non plus besoin de thin provisioning. Dont je n'ai pas bien compris l'intérêt d'ailleurs, mais c'est pas la question. L'intérêt du thin provisioning est de pouvoir créer des volumes d'une taille définie sans allouer immédiatement tout l'espace disque correspondant. Cela permet notamment d'éviter de devoir redimensionner ces volumes et leur contenu (systèmes de fichiers) pour répartir l'espace disque a posteriori.
