Pour les bibliothèques partagées, moi, je suis carrément contre. L'enfer des bibliothèques partagées, c'est l'impossibilité de faire évoluer l'API/ABI de celle-ci. C'est à dire que ni les signatures des fonctions ni le comportement ne peut changer, sans quoi, soit ça casse le code dépendant, soit ça casse le fonctionnement du code dépendant.
Il y a un OS très connu qui était justement connu pour l'instabilité des applications, le problème de compatibilité des installations et c'est justement lui qui a donné le nom que nous utilisons actuellement pour ces m....s : dll.
L'idée, au départ semblait bonne, pourquoi payer plusieurs fois pour le même code?
Mais, une fois mise sur la sellette, on se rend compte que cette économie de bout de chandelle interdit toute évolution d'un code que l'on ne maîtrise plus. Un effort important de documentation doit être fait pour expliquer les effets indirects du code (qui se souvient des crash de l'explorer de fichier à cause d'un plugin IExplorer qui n'a pas supporté une évolution des modules COM...)
Au final, la légendaire stabilité de OSX/MacOS provient principalement dans le fait de ne pas faire de DLL partagées (il y a bien des "frameworks" bas niveau partagés, mais ceux ci sont limités et en général, il y a une couche d'abstraction pour l'utilisation dans votre langage de programmation préféré). Une application = un dossier contenant le binaire et toutes ses dépendances.
Sous linux, on a souvent ces problèmes également (et ce, malgré tout le travail du curage des distributions). Qui n'a pas eu de problème d'une AppImage qui contient une référence vers un driver OpenGL qui est compilé avec une version plus ancienne que le système et donc empêche la version du système d'être utiliséeet échoue au lancement?.
Tout ça à cause du fait que les drivers graphiques récents charge un .so alors que tout le reste de l'application est buildé en statique.
Bref, si le .so ou .dll pouvait crever, on s'en porterait que mieux, AMHA.
En fait, même dans l'embarqué, où l'espace disque est limité, les .so ne font pas sens. Souvent on peut construire le système entier en une seule build, les .so ne servent à rien.
[^] # Re: Éternel problème des SPOF
Posté par xryl669 . En réponse au journal Mon inquiétude sur les dépendances en Rust. Évalué à 2.
Pour les bibliothèques partagées, moi, je suis carrément contre. L'enfer des bibliothèques partagées, c'est l'impossibilité de faire évoluer l'API/ABI de celle-ci. C'est à dire que ni les signatures des fonctions ni le comportement ne peut changer, sans quoi, soit ça casse le code dépendant, soit ça casse le fonctionnement du code dépendant.
Il y a un OS très connu qui était justement connu pour l'instabilité des applications, le problème de compatibilité des installations et c'est justement lui qui a donné le nom que nous utilisons actuellement pour ces m....s : dll.
L'idée, au départ semblait bonne, pourquoi payer plusieurs fois pour le même code?
Mais, une fois mise sur la sellette, on se rend compte que cette économie de bout de chandelle interdit toute évolution d'un code que l'on ne maîtrise plus. Un effort important de documentation doit être fait pour expliquer les effets indirects du code (qui se souvient des crash de l'explorer de fichier à cause d'un plugin IExplorer qui n'a pas supporté une évolution des modules COM...)
Au final, la légendaire stabilité de OSX/MacOS provient principalement dans le fait de ne pas faire de DLL partagées (il y a bien des "frameworks" bas niveau partagés, mais ceux ci sont limités et en général, il y a une couche d'abstraction pour l'utilisation dans votre langage de programmation préféré). Une application = un dossier contenant le binaire et toutes ses dépendances.
Sous linux, on a souvent ces problèmes également (et ce, malgré tout le travail du curage des distributions). Qui n'a pas eu de problème d'une AppImage qui contient une référence vers un driver OpenGL qui est compilé avec une version plus ancienne que le système et donc empêche la version du système d'être utiliséeet échoue au lancement?.
Tout ça à cause du fait que les drivers graphiques récents charge un .so alors que tout le reste de l'application est buildé en statique.
Bref, si le .so ou .dll pouvait crever, on s'en porterait que mieux, AMHA.
En fait, même dans l'embarqué, où l'espace disque est limité, les .so ne font pas sens. Souvent on peut construire le système entier en une seule build, les .so ne servent à rien.