avec par exemple libboost_xxxxx (quelle que soit la librairie).
Lors du build, libboost_xxxxx.1.62 Â Â Â a été "linké".
Mais au prochain "apt upgrade", libboost_xxxxx.1.62 est remplacé par
libboost_xxxxx.1.71 et mon application refuse de s’exécuter faute de
libboost_xxxxx.1.62
Ce qui oblige Í refaire un build dont je ne veux point.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cyrille
Bonsoir A tout hasard geler le paquet dans sa version libboost_xxxxx.1.62 (donc réinstaller cette version, elle doit encore être dans le cache d'apt) apt hold <le paquet> Afin qu'il ne se mette plus Í jour Ou un lien symbolique de la nouvelle version vers la 1.62 Mes 2 sous, mais je ne suis pas un pro.. .mais ça peut ouvrir des pistes ? ++ Cyrille Le Wed, 24 Feb 2021 09:22:43 +0100, Pierre Couderc a écrit :
Bonjour, J'utilise un "main" C++ avec boost avec par exemple libboost_xxxxx (quelle que soit la librairie). Lors du build, libboost_xxxxx.1.62    a été "linké". Mais au prochain "apt upgrade", libboost_xxxxx.1.62 est remplacé par libboost_xxxxx.1.71 et mon application refuse de s’exécuter faute de libboost_xxxxx.1.62 Ce qui oblige Í refaire un build dont je ne veux point. Y-a-t-il une méthode pour éviter ce build ? Merci. PC
-- Je reste lucide, Optimiste jusqu'au suicide, Y a-t-il une autre alternative ? === NACHT UND NEBEL (Txantxo) ===
Bonsoir
A tout hasard
geler le paquet dans sa version libboost_xxxxx.1.62 (donc réinstaller
cette version, elle doit encore être dans le cache d'apt)
apt hold <le paquet>
Afin qu'il ne se mette plus Í jour
Ou un lien symbolique de la nouvelle version vers la 1.62
Mes 2 sous, mais je ne suis pas un pro.. .mais ça peut ouvrir des pistes
?
++
Cyrille
Le Wed, 24 Feb 2021 09:22:43 +0100,
Pierre Couderc <pierre@couderc.eu> a écrit :
Bonjour,
J'utilise un "main" C++ avec boost
avec par exemple libboost_xxxxx (quelle que soit la librairie).
Lors du build, libboost_xxxxx.1.62 Â Â Â a été "linké".
Mais au prochain "apt upgrade", libboost_xxxxx.1.62 est remplacé par
libboost_xxxxx.1.71 et mon application refuse de s’exécuter faute de
libboost_xxxxx.1.62
Ce qui oblige Í refaire un build dont je ne veux point.
Y-a-t-il une méthode pour éviter ce build ?
Merci.
PC
--
Je reste lucide,
Optimiste jusqu'au suicide,
Y a-t-il une autre alternative ?
=== NACHT UND NEBEL (Txantxo) ===
Bonsoir A tout hasard geler le paquet dans sa version libboost_xxxxx.1.62 (donc réinstaller cette version, elle doit encore être dans le cache d'apt) apt hold <le paquet> Afin qu'il ne se mette plus Í jour Ou un lien symbolique de la nouvelle version vers la 1.62 Mes 2 sous, mais je ne suis pas un pro.. .mais ça peut ouvrir des pistes ? ++ Cyrille Le Wed, 24 Feb 2021 09:22:43 +0100, Pierre Couderc a écrit :
Bonjour, J'utilise un "main" C++ avec boost avec par exemple libboost_xxxxx (quelle que soit la librairie). Lors du build, libboost_xxxxx.1.62    a été "linké". Mais au prochain "apt upgrade", libboost_xxxxx.1.62 est remplacé par libboost_xxxxx.1.71 et mon application refuse de s’exécuter faute de libboost_xxxxx.1.62 Ce qui oblige Í refaire un build dont je ne veux point. Y-a-t-il une méthode pour éviter ce build ? Merci. PC
-- Je reste lucide, Optimiste jusqu'au suicide, Y a-t-il une autre alternative ? === NACHT UND NEBEL (Txantxo) ===
Sébastien Dinot
Pierre Couderc a écrit :
Y-a-t-il une méthode pour éviter ce build ?
Le problème vient du fait que vous avez installé le paquet libboost-xxx-dev, qui a automatiquement installé sa dépendance, le paquet libboost-xxx1.62-dev. Or, la dépendance du premier vers le second évolue avec le temps. Il faut donc supprimer le paquet libboost-xxx-dev (ou plus exactement tous les paquets libboost-*-dev) et installer explicitement Í sa place le paquet libboost-xxx1.62-dev. Cela vous apportera la stabilité attendue. Sébastien -- Sébastien Dinot, http://www.palabritudes.net/ Ne goÍ»tez pas au logiciel libre, vous ne pourriez plus vous en passer !
Pierre Couderc a écrit :
Y-a-t-il une méthode pour éviter ce build ?
Le problème vient du fait que vous avez installé le paquet
libboost-xxx-dev, qui a automatiquement installé sa dépendance, le
paquet libboost-xxx1.62-dev. Or, la dépendance du premier vers le second
évolue avec le temps. Il faut donc supprimer le paquet libboost-xxx-dev
(ou plus exactement tous les paquets libboost-*-dev) et installer
explicitement Í sa place le paquet libboost-xxx1.62-dev. Cela vous
apportera la stabilité attendue.
Sébastien
--
Sébastien Dinot, sebastien.dinot@free.fr
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Le problème vient du fait que vous avez installé le paquet libboost-xxx-dev, qui a automatiquement installé sa dépendance, le paquet libboost-xxx1.62-dev. Or, la dépendance du premier vers le second évolue avec le temps. Il faut donc supprimer le paquet libboost-xxx-dev (ou plus exactement tous les paquets libboost-*-dev) et installer explicitement Í sa place le paquet libboost-xxx1.62-dev. Cela vous apportera la stabilité attendue. Sébastien -- Sébastien Dinot, http://www.palabritudes.net/ Ne goÍ»tez pas au logiciel libre, vous ne pourriez plus vous en passer !
Pierre Couderc
merci, cela devrait marcher mais ce n'est pas une solution satisfaisante , en particulier si je livre ce programme.... J'espère que le problème est dans mon build (meson) ou j'ai rajouté "version>=1.62", j'espère que cela fonctionneraa au prochaine "apt upgrade".... On 2/24/21 5:49 PM, Cyrille wrote:
Bonsoir A tout hasard geler le paquet dans sa version libboost_xxxxx.1.62 (donc réinstaller cette version, elle doit encore être dans le cache d'apt) apt hold <le paquet> Afin qu'il ne se mette plus Í jour Ou un lien symbolique de la nouvelle version vers la 1.62 Mes 2 sous, mais je ne suis pas un pro.. .mais ça peut ouvrir des pistes ? ++ Cyrille Le Wed, 24 Feb 2021 09:22:43 +0100, Pierre Couderc a écrit :
Bonjour, J'utilise un "main" C++ avec boost avec par exemple libboost_xxxxx (quelle que soit la librairie). Lors du build, libboost_xxxxx.1.62    a été "linké". Mais au prochain "apt upgrade", libboost_xxxxx.1.62 est remplacé par libboost_xxxxx.1.71 et mon application refuse de s’exécuter faute de libboost_xxxxx.1.62 Ce qui oblige Í refaire un build dont je ne veux point. Y-a-t-il une méthode pour éviter ce build ? Merci. PC
merci, cela devrait marcher mais ce n'est pas une solution satisfaisante
, en particulier si je livre ce programme....
J'espère que le problème est dans mon build (meson) ou j'ai rajouté
"version>=1.62", j'espère que cela fonctionneraa au prochaine "apt
upgrade"....
On 2/24/21 5:49 PM, Cyrille wrote:
Bonsoir
A tout hasard
geler le paquet dans sa version libboost_xxxxx.1.62 (donc réinstaller
cette version, elle doit encore être dans le cache d'apt)
apt hold <le paquet>
Afin qu'il ne se mette plus Í jour
Ou un lien symbolique de la nouvelle version vers la 1.62
Mes 2 sous, mais je ne suis pas un pro.. .mais ça peut ouvrir des pistes
?
++
Cyrille
Le Wed, 24 Feb 2021 09:22:43 +0100,
Pierre Couderc <pierre@couderc.eu> a écrit :
Bonjour,
J'utilise un "main" C++ avec boost
avec par exemple libboost_xxxxx (quelle que soit la librairie).
Lors du build, libboost_xxxxx.1.62 Â Â Â a été "linké".
Mais au prochain "apt upgrade", libboost_xxxxx.1.62 est remplacé par
libboost_xxxxx.1.71 et mon application refuse de s’exécuter faute de
libboost_xxxxx.1.62
Ce qui oblige Í refaire un build dont je ne veux point.
merci, cela devrait marcher mais ce n'est pas une solution satisfaisante , en particulier si je livre ce programme.... J'espère que le problème est dans mon build (meson) ou j'ai rajouté "version>=1.62", j'espère que cela fonctionneraa au prochaine "apt upgrade".... On 2/24/21 5:49 PM, Cyrille wrote:
Bonsoir A tout hasard geler le paquet dans sa version libboost_xxxxx.1.62 (donc réinstaller cette version, elle doit encore être dans le cache d'apt) apt hold <le paquet> Afin qu'il ne se mette plus Í jour Ou un lien symbolique de la nouvelle version vers la 1.62 Mes 2 sous, mais je ne suis pas un pro.. .mais ça peut ouvrir des pistes ? ++ Cyrille Le Wed, 24 Feb 2021 09:22:43 +0100, Pierre Couderc a écrit :
Bonjour, J'utilise un "main" C++ avec boost avec par exemple libboost_xxxxx (quelle que soit la librairie). Lors du build, libboost_xxxxx.1.62    a été "linké". Mais au prochain "apt upgrade", libboost_xxxxx.1.62 est remplacé par libboost_xxxxx.1.71 et mon application refuse de s’exécuter faute de libboost_xxxxx.1.62 Ce qui oblige Í refaire un build dont je ne veux point. Y-a-t-il une méthode pour éviter ce build ? Merci. PC
Pierre Couderc
On 2/24/21 9:29 PM, Sébastien Dinot wrote:
Pierre Couderc a écrit :
Y-a-t-il une méthode pour éviter ce build ?
Le problème vient du fait que vous avez installé le paquet libboost-xxx-dev, qui a automatiquement installé sa dépendance, le paquet libboost-xxx1.62-dev. Or, la dépendance du premier vers le second évolue avec le temps. Il faut donc supprimer le paquet libboost-xxx-dev (ou plus exactement tous les paquets libboost-*-dev) et installer explicitement Í sa place le paquet libboost-xxx1.62-dev. Cela vous apportera la stabilité attendue.
merci, cela devrait marcher mais ce n'est pas une solution satisfaisante , en particulier si je "livre" ce programme sur un autre PC (o͹ je n'aurai pas besoin libboost-xxx-dev). J'espère que le problème est dans mon build (meson) ou j'ai rajouté "version>=1.62", j'espère que cela fonctionnera au prochaine "apt upgrade"....
On 2/24/21 9:29 PM, Sébastien Dinot wrote:
Pierre Couderc a écrit :
Y-a-t-il une méthode pour éviter ce build ?
Le problème vient du fait que vous avez installé le paquet
libboost-xxx-dev, qui a automatiquement installé sa dépendance, le
paquet libboost-xxx1.62-dev. Or, la dépendance du premier vers le second
évolue avec le temps. Il faut donc supprimer le paquet libboost-xxx-dev
(ou plus exactement tous les paquets libboost-*-dev) et installer
explicitement Í sa place le paquet libboost-xxx1.62-dev. Cela vous
apportera la stabilité attendue.
merci, cela devrait marcher mais ce n'est pas une solution satisfaisante
, en particulier si je "livre" ce programme sur un autre PC (o͹ je
n'aurai pas besoin libboost-xxx-dev).
J'espère que le problème est dans mon build (meson) ou j'ai rajouté
"version>=1.62", j'espère que cela fonctionnera au prochaine "apt
upgrade"....
Le problème vient du fait que vous avez installé le paquet libboost-xxx-dev, qui a automatiquement installé sa dépendance, le paquet libboost-xxx1.62-dev. Or, la dépendance du premier vers le second évolue avec le temps. Il faut donc supprimer le paquet libboost-xxx-dev (ou plus exactement tous les paquets libboost-*-dev) et installer explicitement Í sa place le paquet libboost-xxx1.62-dev. Cela vous apportera la stabilité attendue.
merci, cela devrait marcher mais ce n'est pas une solution satisfaisante , en particulier si je "livre" ce programme sur un autre PC (o͹ je n'aurai pas besoin libboost-xxx-dev). J'espère que le problème est dans mon build (meson) ou j'ai rajouté "version>=1.62", j'espère que cela fonctionnera au prochaine "apt upgrade"....
Sébastien Dinot
Pierre Couderc a écrit :
merci, cela devrait marcher mais ce n'est pas une solution satisfaisante , en particulier si je "livre" ce programme sur un autre PC (o͹ je n'aurai pas besoin libboost-xxx-dev).
Dans ce cas, il faudra juste déclarer une dépendance Í libboost-xxx1.62.
J'espère que le problème est dans mon build (meson) ou j'ai rajouté "version>=1.62", j'espère que cela fonctionnera au prochaine "apt upgrade"....
Cette déclaration de dépendance dans Meson permet au développeur de vérifier que l'environnement requis pour compiler l'outil est bien conforme, mais il n'assure nullement qu'un exécutable compilé avec la version 1.62 fonctionnera avec la version 1.74. On se trouve lÍ face Í un dilemme vieux comme les systèmes d'exploitation ou presque, sachant qu'il existe deux stratégies opposées et que chacune a ses forces et ses faiblesses : 1. Créer, comme le font les systèmes MS-Windows et MacOS, mais aussi les outils tels que Docker, Snap ou AppImage, des paquets auto-portants (i.e. qui contiennent toutes les bibliothèques et ressources dont a besoin l'application pour fonctionner). 2. Créer, comme le fait tout système Unix, des outils compilés de manière homogène pour la cible considérée, ce qui leur permet de se satisfaire des versions des bibliothèques déployées nativement sur le système cible. La stratégie 1 est pratique pour le développeur (il se libère des contingences du système), mais introduit une énorme faille de sécurité : on peut patcher le système d'exploitation sans que cela ait le moindre effet sur l'application et donc, sans que cela corrige les failles de sécurité. En outre, on surconsomme de l'espace disque et en mémoire vive, mais qui se soucie de ce détail Í l'heure du conteneur roi. La stratégie 2 est pratique pour l'admin. sys. car le patch du système d'exploitation corrige le problème au niveau de toutes les applications et la consommation de disque et de mémoire vive est optimisée. Mais cette stratégie est une vraie plaie pour tout développeur créant une application multi-cible (et lÍ , je ne parle même pas de MS-Windows ou de MacOS, mais juste des différentes distributions GNU/Linux dans leurs différentes versions). La stratégie 1 est en train de l'emporter sur la 2 et donc, les développeurs sur les admin. sys., avec la promesse que les conteneurisations de toute sorte créeront des espaces isolés qui ne permettront pas aux failles de sécurité de s'étendre au delÍ de l'application qui les engendre. Certains semblent se contenter de cet état de fait. J'y vois pour ma part un danger sérieux, car elle déporte la charge de la veille sécuritaire sur les développeurs, qui ne s'en soucient généralement pas (qui parmi les développeurs abonnés Í cette liste est abonné Í une liste d'annonce de CVE et surveille les failles affectant les bibliothèques qu'il utilise ? Probablement personne). Sébastien -- Sébastien Dinot, http://www.palabritudes.net/ Ne goÍ»tez pas au logiciel libre, vous ne pourriez plus vous en passer !
Pierre Couderc a écrit :
merci, cela devrait marcher mais ce n'est pas une solution
satisfaisante , en particulier si je "livre" ce programme sur un autre
PC (o͹ je n'aurai pas besoin libboost-xxx-dev).
Dans ce cas, il faudra juste déclarer une dépendance Í libboost-xxx1.62.
J'espère que le problème est dans mon build (meson) ou j'ai rajouté
"version>=1.62", j'espère que cela fonctionnera au prochaine "apt
upgrade"....
Cette déclaration de dépendance dans Meson permet au développeur de
vérifier que l'environnement requis pour compiler l'outil est bien
conforme, mais il n'assure nullement qu'un exécutable compilé avec la
version 1.62 fonctionnera avec la version 1.74.
On se trouve lÍ face Í un dilemme vieux comme les systèmes
d'exploitation ou presque, sachant qu'il existe deux stratégies opposées
et que chacune a ses forces et ses faiblesses :
1. Créer, comme le font les systèmes MS-Windows et MacOS, mais aussi les
outils tels que Docker, Snap ou AppImage, des paquets auto-portants
(i.e. qui contiennent toutes les bibliothèques et ressources dont
a besoin l'application pour fonctionner).
2. Créer, comme le fait tout système Unix, des outils compilés de
manière homogène pour la cible considérée, ce qui leur permet de se
satisfaire des versions des bibliothèques déployées nativement sur le
système cible.
La stratégie 1 est pratique pour le développeur (il se libère des
contingences du système), mais introduit une énorme faille de sécurité :
on peut patcher le système d'exploitation sans que cela ait le moindre
effet sur l'application et donc, sans que cela corrige les failles de
sécurité. En outre, on surconsomme de l'espace disque et en mémoire
vive, mais qui se soucie de ce détail Í l'heure du conteneur roi.
La stratégie 2 est pratique pour l'admin. sys. car le patch du système
d'exploitation corrige le problème au niveau de toutes les applications
et la consommation de disque et de mémoire vive est optimisée. Mais
cette stratégie est une vraie plaie pour tout développeur créant une
application multi-cible (et lÍ , je ne parle même pas de MS-Windows ou de
MacOS, mais juste des différentes distributions GNU/Linux dans leurs
différentes versions).
La stratégie 1 est en train de l'emporter sur la 2 et donc, les
développeurs sur les admin. sys., avec la promesse que les
conteneurisations de toute sorte créeront des espaces isolés qui ne
permettront pas aux failles de sécurité de s'étendre au delÍ de
l'application qui les engendre. Certains semblent se contenter de cet
état de fait. J'y vois pour ma part un danger sérieux, car elle déporte
la charge de la veille sécuritaire sur les développeurs, qui ne s'en
soucient généralement pas (qui parmi les développeurs abonnés Í cette
liste est abonné Í une liste d'annonce de CVE et surveille les failles
affectant les bibliothèques qu'il utilise ? Probablement personne).
Sébastien
--
Sébastien Dinot, sebastien.dinot@free.fr
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
merci, cela devrait marcher mais ce n'est pas une solution satisfaisante , en particulier si je "livre" ce programme sur un autre PC (o͹ je n'aurai pas besoin libboost-xxx-dev).
Dans ce cas, il faudra juste déclarer une dépendance Í libboost-xxx1.62.
J'espère que le problème est dans mon build (meson) ou j'ai rajouté "version>=1.62", j'espère que cela fonctionnera au prochaine "apt upgrade"....
Cette déclaration de dépendance dans Meson permet au développeur de vérifier que l'environnement requis pour compiler l'outil est bien conforme, mais il n'assure nullement qu'un exécutable compilé avec la version 1.62 fonctionnera avec la version 1.74. On se trouve lÍ face Í un dilemme vieux comme les systèmes d'exploitation ou presque, sachant qu'il existe deux stratégies opposées et que chacune a ses forces et ses faiblesses : 1. Créer, comme le font les systèmes MS-Windows et MacOS, mais aussi les outils tels que Docker, Snap ou AppImage, des paquets auto-portants (i.e. qui contiennent toutes les bibliothèques et ressources dont a besoin l'application pour fonctionner). 2. Créer, comme le fait tout système Unix, des outils compilés de manière homogène pour la cible considérée, ce qui leur permet de se satisfaire des versions des bibliothèques déployées nativement sur le système cible. La stratégie 1 est pratique pour le développeur (il se libère des contingences du système), mais introduit une énorme faille de sécurité : on peut patcher le système d'exploitation sans que cela ait le moindre effet sur l'application et donc, sans que cela corrige les failles de sécurité. En outre, on surconsomme de l'espace disque et en mémoire vive, mais qui se soucie de ce détail Í l'heure du conteneur roi. La stratégie 2 est pratique pour l'admin. sys. car le patch du système d'exploitation corrige le problème au niveau de toutes les applications et la consommation de disque et de mémoire vive est optimisée. Mais cette stratégie est une vraie plaie pour tout développeur créant une application multi-cible (et lÍ , je ne parle même pas de MS-Windows ou de MacOS, mais juste des différentes distributions GNU/Linux dans leurs différentes versions). La stratégie 1 est en train de l'emporter sur la 2 et donc, les développeurs sur les admin. sys., avec la promesse que les conteneurisations de toute sorte créeront des espaces isolés qui ne permettront pas aux failles de sécurité de s'étendre au delÍ de l'application qui les engendre. Certains semblent se contenter de cet état de fait. J'y vois pour ma part un danger sérieux, car elle déporte la charge de la veille sécuritaire sur les développeurs, qui ne s'en soucient généralement pas (qui parmi les développeurs abonnés Í cette liste est abonné Í une liste d'annonce de CVE et surveille les failles affectant les bibliothèques qu'il utilise ? Probablement personne). Sébastien -- Sébastien Dinot, http://www.palabritudes.net/ Ne goÍ»tez pas au logiciel libre, vous ne pourriez plus vous en passer !
