Boost version

Le
Pierre Couderc
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
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Cyrille
Le #26568755
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
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
Le #26568808
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
Le #26568822
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
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
Le #26568824
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"....
Sébastien Dinot
Le #26568840
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 !
Poster une réponse
Anonyme