J'aimerais avoir votre avis sur la gestion des dépendances de MacOS
comparée à celle de linux.
Sous Mac (en applications natives), il n'y a pas de dépendances, toutes
les librairies nécessaires à l'appli sont dans le folder .app de
l'application.
Sous linux, il y a une gestion complexe des dépendances.
Donc sur Mac pour installer une appli on la copie sur son disque dur et
on lui donne les autorisations d'exécution (la demande de mot de passe à
l'install dans le dossier /Applications).
Sous Linux vous savez comment cela fonctionne.
Un exemple ou cela serait utile :
- Ubuntu server 9.10
- python 2.6 (version installée par défaut)
- apt-get fail2ban
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.
Donc il faut faire en plus
- apt-get install python2.5
- modifier les fichiers de fail2ban pour utiliser cette version
Ce ne serait pas arrivé sur Mac.
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La 2.6 étant installée, pas de prob pour le gestionnaire de paquet par contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet. L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
JEf wrote in message <Ytadnf15tqR57cPRnZ2dnUVZ8kWdnZ2d@giganews.com>:
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet.
L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La 2.6 étant installée, pas de prob pour le gestionnaire de paquet par contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet. L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
JEf
On 08/08/10 10:59, Nicolas George wrote:
JEf wrote in message:
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La 2.6 étant installée, pas de prob pour le gestionnaire de paquet par contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet. L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
C'est indiqué dans les faq de fail2ban, c'est un prob connu (sous 9.04 et 9.10)
Un exemple http://www.howtoforge.com/forums/showthread.php?t4886
Pour répondre à la question, oui j'ai indiqué le prob chez ubuntu.
HTH
JEf
On 08/08/10 10:59, Nicolas George wrote:
JEf wrote in message<Ytadnf15tqR57cPRnZ2dnUVZ8kWdnZ2d@giganews.com>:
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet.
L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
C'est indiqué dans les faq de fail2ban, c'est un prob connu (sous 9.04
et 9.10)
Un exemple
http://www.howtoforge.com/forums/showthread.php?t4886
Pour répondre à la question, oui j'ai indiqué le prob chez ubuntu.
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La 2.6 étant installée, pas de prob pour le gestionnaire de paquet par contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet. L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
C'est indiqué dans les faq de fail2ban, c'est un prob connu (sous 9.04 et 9.10)
Un exemple http://www.howtoforge.com/forums/showthread.php?t4886
Pour répondre à la question, oui j'ai indiqué le prob chez ubuntu.
HTH
JEf
JKB
Le 08 Aug 2010 08:59:48 GMT, Nicolas George <nicolas$ écrivait :
JEf wrote in message :
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La 2.6 étant installée, pas de prob pour le gestionnaire de paquet par contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet. L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
Ça dépend. Il y a des cas où tu ne peux pas te permettre de faire autre chose que de lier un soft en statique (ce qui revient au même que de coller les bibliothèques partagées dans un répertoire spécifique à l'application). Lorsque tu restes dans un environnement Linux, tu peux souvent faire autrement, mais lorsque tu écris un soft un peu gros et réellement portable, c'est beaucoup plus difficile. Il est quasiment impossible de trouver directement la bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible et généralement, lesdites bibliothèques ne se compilent pas out of the box. Tu vas me dire que c'est parce qu'elles sont écrites avec des pieds et tu auras raison. Le problème n'est pa de savoir si elles sont bien ou mal écrites mais si elles sont disponibles facilement sur l'OS cible.
Si tu veux un exemple marrant, regarde file-5.03 et essaye simplement de compiler la chose sous Linux/sparc, NetBSD/alpha ou openVMS/Itanium puis de l'utiliser. Sur toutes les architecture à alignement mémoire, ça merdoie allègrement. Regarde aussi ncurses sous Solaris (qui est liée par défaut à -lform pour sa version statique, lequel lform provient de curses livré par Sun et non de ncurses. Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !). Bref, dans la vraie vie, il est idiot de dire que quelqu'un qui embarque dans un logiciel ce qu'il faut pour qu'il tourne correctement ne fait pas les choses bien.
Un autre exemple qui m'emmerde actuellement : j'ai une application qui utilise à la fois la libpq du système (debian stable) et openssl 1.0.0. Regarde le résultat pour t'amuser et ce qu'il faut faire pour contourner le problème. Ça termine par des recompilations de postgres et un grand coup de LD_PRELOAD ou d'édition des liens statiques.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le 08 Aug 2010 08:59:48 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JEf wrote in message <Ytadnf15tqR57cPRnZ2dnUVZ8kWdnZ2d@giganews.com>:
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet.
L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
Ça dépend. Il y a des cas où tu ne peux pas te permettre de faire
autre chose que de lier un soft en statique (ce qui revient au même
que de coller les bibliothèques partagées dans un répertoire
spécifique à l'application). Lorsque tu restes dans un environnement
Linux, tu peux souvent faire autrement, mais lorsque tu écris un
soft un peu gros et réellement portable, c'est beaucoup plus
difficile. Il est quasiment impossible de trouver directement la
bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible
et généralement, lesdites bibliothèques ne se compilent pas out of
the box. Tu vas me dire que c'est parce qu'elles sont écrites avec
des pieds et tu auras raison. Le problème n'est pa de savoir si
elles sont bien ou mal écrites mais si elles sont disponibles
facilement sur l'OS cible.
Si tu veux un exemple marrant, regarde file-5.03 et essaye
simplement de compiler la chose sous Linux/sparc, NetBSD/alpha ou
openVMS/Itanium puis de l'utiliser. Sur toutes les architecture à
alignement mémoire, ça merdoie allègrement. Regarde aussi ncurses
sous Solaris (qui est liée par défaut à -lform pour sa version statique,
lequel lform provient de curses livré par Sun et non de ncurses.
Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).
Bref, dans la vraie vie, il est idiot de dire que quelqu'un qui embarque
dans un logiciel ce qu'il faut pour qu'il tourne correctement ne fait pas
les choses bien.
Un autre exemple qui m'emmerde actuellement : j'ai une application
qui utilise à la fois la libpq du système (debian stable) et openssl
1.0.0. Regarde le résultat pour t'amuser et ce qu'il faut faire pour
contourner le problème. Ça termine par des recompilations de
postgres et un grand coup de LD_PRELOAD ou d'édition des liens
statiques.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le 08 Aug 2010 08:59:48 GMT, Nicolas George <nicolas$ écrivait :
JEf wrote in message :
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La 2.6 étant installée, pas de prob pour le gestionnaire de paquet par contre fail2ban ne fonctionne pas bien.
Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet. L'as-tu fait ?
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
On a la passion de faire les choses bien ou on ne l'a pas.
Ça dépend. Il y a des cas où tu ne peux pas te permettre de faire autre chose que de lier un soft en statique (ce qui revient au même que de coller les bibliothèques partagées dans un répertoire spécifique à l'application). Lorsque tu restes dans un environnement Linux, tu peux souvent faire autrement, mais lorsque tu écris un soft un peu gros et réellement portable, c'est beaucoup plus difficile. Il est quasiment impossible de trouver directement la bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible et généralement, lesdites bibliothèques ne se compilent pas out of the box. Tu vas me dire que c'est parce qu'elles sont écrites avec des pieds et tu auras raison. Le problème n'est pa de savoir si elles sont bien ou mal écrites mais si elles sont disponibles facilement sur l'OS cible.
Si tu veux un exemple marrant, regarde file-5.03 et essaye simplement de compiler la chose sous Linux/sparc, NetBSD/alpha ou openVMS/Itanium puis de l'utiliser. Sur toutes les architecture à alignement mémoire, ça merdoie allègrement. Regarde aussi ncurses sous Solaris (qui est liée par défaut à -lform pour sa version statique, lequel lform provient de curses livré par Sun et non de ncurses. Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !). Bref, dans la vraie vie, il est idiot de dire que quelqu'un qui embarque dans un logiciel ce qu'il faut pour qu'il tourne correctement ne fait pas les choses bien.
Un autre exemple qui m'emmerde actuellement : j'ai une application qui utilise à la fois la libpq du système (debian stable) et openssl 1.0.0. Regarde le résultat pour t'amuser et ce qu'il faut faire pour contourner le problème. Ça termine par des recompilations de postgres et un grand coup de LD_PRELOAD ou d'édition des liens statiques.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Tonton Th
On 08/08/2010 10:55 AM, JEf wrote:
Sous linux, il y a une gestion complexe des dépendances.
En fait, non, pas du tout, efface :)
Linux, ce n'est que le noyau, le kerne, la quenelle, le moteur interne du système. Ensuite, là-dessus, il y a les bibliothèques de fonctions de base, sur lesquelles sont construites d'autre bibliothèques plus "avancées", par exemple ce qui permet de lire une image encodée en TIFF, en encore là-dessus les applications, genre le soft qui te permet de regarder une image tiff.
C'est l'assemblage de tout ces morceaux de logiciels que l'on appelle une "distribution Linux", et chacune de ces distributions gère les dépendances entre les diverses briques logicielles à sa façon.
Je ne pratique que deux de ces distributions : Debian (et ses dérivées) et Slackware. La première a un truc magique extrèmement puissant pour gérer l'arbre/le graphe des dépendances entre les couches de briques, les applis, les trucs et les machins. La seconde considère que celui qui tape sur le clavier peut lui-même gérer ces dépendances et ne s'en préoccupe donc absolument pas.
Pour moi, ces deux façons de faire, placées chacune à une des deux extrèmités de l'axe des façons d'appréhender la gestion des dépendances, sont aussi positives l'une que l'autre. Par contre, il y a des compromis entre ces deux points pivots, qui, euh...
Quand à tirer les libs dans le répertoire de l'application, c'est quand même un truc de merde. Amha.
-- Et pendant ce temps-là, dans le golfe du Mexique...
On 08/08/2010 10:55 AM, JEf wrote:
Sous linux, il y a une gestion complexe des dépendances.
En fait, non, pas du tout, efface :)
Linux, ce n'est que le noyau, le kerne, la quenelle, le
moteur interne du système. Ensuite, là-dessus, il y a
les bibliothèques de fonctions de base, sur lesquelles
sont construites d'autre bibliothèques plus "avancées",
par exemple ce qui permet de lire une image encodée en
TIFF, en encore là-dessus les applications, genre le soft
qui te permet de regarder une image tiff.
C'est l'assemblage de tout ces morceaux de logiciels
que l'on appelle une "distribution Linux", et chacune
de ces distributions gère les dépendances entre les
diverses briques logicielles à sa façon.
Je ne pratique que deux de ces distributions : Debian
(et ses dérivées) et Slackware. La première a un truc
magique extrèmement puissant pour gérer l'arbre/le graphe
des dépendances entre les couches de briques, les applis,
les trucs et les machins. La seconde considère que celui
qui tape sur le clavier peut lui-même gérer ces dépendances
et ne s'en préoccupe donc absolument pas.
Pour moi, ces deux façons de faire, placées chacune à une
des deux extrèmités de l'axe des façons d'appréhender la
gestion des dépendances, sont aussi positives l'une que
l'autre. Par contre, il y a des compromis entre ces deux
points pivots, qui, euh...
Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.
--
Et pendant ce temps-là, dans le golfe du Mexique...
Sous linux, il y a une gestion complexe des dépendances.
En fait, non, pas du tout, efface :)
Linux, ce n'est que le noyau, le kerne, la quenelle, le moteur interne du système. Ensuite, là-dessus, il y a les bibliothèques de fonctions de base, sur lesquelles sont construites d'autre bibliothèques plus "avancées", par exemple ce qui permet de lire une image encodée en TIFF, en encore là-dessus les applications, genre le soft qui te permet de regarder une image tiff.
C'est l'assemblage de tout ces morceaux de logiciels que l'on appelle une "distribution Linux", et chacune de ces distributions gère les dépendances entre les diverses briques logicielles à sa façon.
Je ne pratique que deux de ces distributions : Debian (et ses dérivées) et Slackware. La première a un truc magique extrèmement puissant pour gérer l'arbre/le graphe des dépendances entre les couches de briques, les applis, les trucs et les machins. La seconde considère que celui qui tape sur le clavier peut lui-même gérer ces dépendances et ne s'en préoccupe donc absolument pas.
Pour moi, ces deux façons de faire, placées chacune à une des deux extrèmités de l'axe des façons d'appréhender la gestion des dépendances, sont aussi positives l'une que l'autre. Par contre, il y a des compromis entre ces deux points pivots, qui, euh...
Quand à tirer les libs dans le répertoire de l'application, c'est quand même un truc de merde. Amha.
-- Et pendant ce temps-là, dans le golfe du Mexique...
Patrick Lamaizière
JKB :
Un autre exemple qui m'emmerde actuellement : j'ai une application
...
Et Libtool ça n'aide pas ? (c't une vraie question).
JKB :
Un autre exemple qui m'emmerde actuellement : j'ai une application
...
Et Libtool ça n'aide pas ? (c't une vraie question).
Un autre exemple qui m'emmerde actuellement : j'ai une application
...
Et Libtool ça n'aide pas ? (c't une vraie question).
JEf
On 08/08/10 22:24, Tonton Th wrote:
Quand à tirer les libs dans le répertoire de l'application, c'est quand même un truc de merde. Amha.
Pourquoi ? Sur un serveur où on recherche des gains de performance je ne dis pas (et encore quand je vois le gaspi de la mode du cloud et autres systèmes de machines virtuelles). Mais sur un desktop grand public où le but est que toute appli doit fonctionner peu importe les autres softs installés ?
JEf
On 08/08/10 22:24, Tonton Th wrote:
Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.
Pourquoi ? Sur un serveur où on recherche des gains de performance je ne
dis pas (et encore quand je vois le gaspi de la mode du cloud et autres
systèmes de machines virtuelles). Mais sur un desktop grand public où le
but est que toute appli doit fonctionner peu importe les autres softs
installés ?
Quand à tirer les libs dans le répertoire de l'application, c'est quand même un truc de merde. Amha.
Pourquoi ? Sur un serveur où on recherche des gains de performance je ne dis pas (et encore quand je vois le gaspi de la mode du cloud et autres systèmes de machines virtuelles). Mais sur un desktop grand public où le but est que toute appli doit fonctionner peu importe les autres softs installés ?
JEf
JKB
Le Mon, 09 Aug 2010 21:27:39 +0200, Patrick Lamaizière écrivait :
JKB :
Un autre exemple qui m'emmerde actuellement : j'ai une application
...
Et Libtool ça n'aide pas ? (c't une vraie question).
Pas vraiment. Libtool est buggué jusqu'à la moëlle et rempli de gnueries même pas compatibles avec les outils GNU. Là, je bataille avec la compilation de GSL 1.14 sous eCS. J'ai installé tous les outils GNU et je suis obligé de triturer le ltmain.sh à grands coups de sed pour obtenir après _deux_ passage de configure quelque chose de potable. Libtool, ça n'a été écrit que pour du GNU en emmerdant prodigieusement tout ce qui n'est pas GNU ou qui est GNU mais un peu ancien.
Regarde juste un peu les joyeusetés comme ${1 + "$@"} dans un shell plus vieux qu'un bash 4.x (par exemple un bash 3.2 livré par défaut avec eCS)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 09 Aug 2010 21:27:39 +0200,
Patrick Lamaizière <adresse@est.invalid> écrivait :
JKB :
Un autre exemple qui m'emmerde actuellement : j'ai une application
...
Et Libtool ça n'aide pas ? (c't une vraie question).
Pas vraiment. Libtool est buggué jusqu'à la moëlle et rempli de
gnueries même pas compatibles avec les outils GNU. Là, je bataille
avec la compilation de GSL 1.14 sous eCS. J'ai installé tous les
outils GNU et je suis obligé de triturer le ltmain.sh à grands coups
de sed pour obtenir après _deux_ passage de configure quelque chose
de potable. Libtool, ça n'a été écrit que pour du GNU en emmerdant
prodigieusement tout ce qui n'est pas GNU ou qui est GNU mais un peu
ancien.
Regarde juste un peu les joyeusetés comme ${1 + "$@"} dans un shell
plus vieux qu'un bash 4.x (par exemple un bash 3.2 livré par défaut
avec eCS)
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 09 Aug 2010 21:27:39 +0200, Patrick Lamaizière écrivait :
JKB :
Un autre exemple qui m'emmerde actuellement : j'ai une application
...
Et Libtool ça n'aide pas ? (c't une vraie question).
Pas vraiment. Libtool est buggué jusqu'à la moëlle et rempli de gnueries même pas compatibles avec les outils GNU. Là, je bataille avec la compilation de GSL 1.14 sous eCS. J'ai installé tous les outils GNU et je suis obligé de triturer le ltmain.sh à grands coups de sed pour obtenir après _deux_ passage de configure quelque chose de potable. Libtool, ça n'a été écrit que pour du GNU en emmerdant prodigieusement tout ce qui n'est pas GNU ou qui est GNU mais un peu ancien.
Regarde juste un peu les joyeusetés comme ${1 + "$@"} dans un shell plus vieux qu'un bash 4.x (par exemple un bash 3.2 livré par défaut avec eCS)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Tonton Th
On 08/09/2010 10:15 PM, JEf wrote:
On 08/08/10 22:24, Tonton Th wrote:
Quand à tirer les libs dans le répertoire de l'application, c'est quand même un truc de merde. Amha.
systèmes de machines virtuelles). Mais sur un desktop grand public où le but est que toute appli doit fonctionner peu importe les autres softs installés ?
C'est toujours un truc de merde.
-- Et pendant ce temps-là, dans le golfe du Mexique...
On 08/09/2010 10:15 PM, JEf wrote:
On 08/08/10 22:24, Tonton Th wrote:
Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.
systèmes de machines virtuelles). Mais sur un desktop grand public où le
but est que toute appli doit fonctionner peu importe les autres softs
installés ?
C'est toujours un truc de merde.
--
Et pendant ce temps-là, dans le golfe du Mexique...
Quand à tirer les libs dans le répertoire de l'application, c'est quand même un truc de merde. Amha.
systèmes de machines virtuelles). Mais sur un desktop grand public où le but est que toute appli doit fonctionner peu importe les autres softs installés ?
C'est toujours un truc de merde.
-- Et pendant ce temps-là, dans le golfe du Mexique...
Nicolas George
JKB wrote in message :
Il est quasiment impossible de trouver directement la bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible
Je ne comprends pas ce que tu veux dire par « trouver ». S'il s'agit de choisir les bons -I et -L pour avoir des versions cohérentes des bibliothèques, ce n'est pas le problème du développeur, c'est le problème de celui qui cherche à compiler un paquet sur un système incohérent.
Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).
Un bug ponctuel, même si les développeurs traînent à le corriger (ce qui me surprend, THomas Dickey m'ayant toujours semblé très réactif) n'invalide pas un principe.
Un autre exemple qui m'emmerde actuellement : j'ai une application qui utilise à la fois la libpq du système (debian stable) et openssl 1.0.0. Regarde le résultat pour t'amuser
Ben c'est ta faute, tu mélanges les choses, tu cherches les ennuis. Utilise openssl du système, la libpq du système sera compilée avec et tu n'auras pas de soucis.
JKB wrote in message <slrni5t2ak.shl.jkb@rayleigh.systella.fr>:
Il est quasiment impossible de trouver directement la
bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible
Je ne comprends pas ce que tu veux dire par « trouver ». S'il s'agit de
choisir les bons -I et -L pour avoir des versions cohérentes des
bibliothèques, ce n'est pas le problème du développeur, c'est le problème de
celui qui cherche à compiler un paquet sur un système incohérent.
Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).
Un bug ponctuel, même si les développeurs traînent à le corriger (ce qui me
surprend, THomas Dickey m'ayant toujours semblé très réactif) n'invalide pas
un principe.
Un autre exemple qui m'emmerde actuellement : j'ai une application
qui utilise à la fois la libpq du système (debian stable) et openssl
1.0.0. Regarde le résultat pour t'amuser
Ben c'est ta faute, tu mélanges les choses, tu cherches les ennuis. Utilise
openssl du système, la libpq du système sera compilée avec et tu n'auras pas
de soucis.
Il est quasiment impossible de trouver directement la bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible
Je ne comprends pas ce que tu veux dire par « trouver ». S'il s'agit de choisir les bons -I et -L pour avoir des versions cohérentes des bibliothèques, ce n'est pas le problème du développeur, c'est le problème de celui qui cherche à compiler un paquet sur un système incohérent.
Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).
Un bug ponctuel, même si les développeurs traînent à le corriger (ce qui me surprend, THomas Dickey m'ayant toujours semblé très réactif) n'invalide pas un principe.
Un autre exemple qui m'emmerde actuellement : j'ai une application qui utilise à la fois la libpq du système (debian stable) et openssl 1.0.0. Regarde le résultat pour t'amuser
Ben c'est ta faute, tu mélanges les choses, tu cherches les ennuis. Utilise openssl du système, la libpq du système sera compilée avec et tu n'auras pas de soucis.
JKB
Le 10 Aug 2010 08:39:41 GMT, Nicolas George <nicolas$ écrivait :
JKB wrote in message :
Il est quasiment impossible de trouver directement la bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible
Je ne comprends pas ce que tu veux dire par « trouver ». S'il s'agit de choisir les bons -I et -L pour avoir des versions cohérentes des bibliothèques, ce n'est pas le problème du développeur, c'est le problème de celui qui cherche à compiler un paquet sur un système incohérent.
C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses, mais un curses fourni par Sun^Oracle qui est subtilement incompatible avec ncurses. Tu dois donc recompiler ncurses, et là, tu as intérêt de lier statiquement le ncurses à ton exécutable sous peine de voir des choses amusantes dans les utilitaires du système ou de coller la libncurses.so dans un répertoire spécifique à ton application et demander à tes utilisateurs de lancer ton application avec un LD_PRELOAD. Il n'y a pas que Linux dans la vie.
Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).
Un bug ponctuel, même si les développeurs traînent à le corriger (ce qui me surprend, THomas Dickey m'ayant toujours semblé très réactif) n'invalide pas un principe.
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures cibles n'étaient pas vraiment une priorité.
Un autre exemple qui m'emmerde actuellement : j'ai une application qui utilise à la fois la libpq du système (debian stable) et openssl 1.0.0. Regarde le résultat pour t'amuser
Ben c'est ta faute, tu mélanges les choses, tu cherches les ennuis. Utilise openssl du système, la libpq du système sera compilée avec et tu n'auras pas de soucis.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as qu'à utiliser 0.9.8x ' ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
Le 10 Aug 2010 08:39:41 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB wrote in message <slrni5t2ak.shl.jkb@rayleigh.systella.fr>:
Il est quasiment impossible de trouver directement la
bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible
Je ne comprends pas ce que tu veux dire par « trouver ». S'il s'agit de
choisir les bons -I et -L pour avoir des versions cohérentes des
bibliothèques, ce n'est pas le problème du développeur, c'est le problème de
celui qui cherche à compiler un paquet sur un système incohérent.
C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses,
mais un curses fourni par Sun^Oracle qui est subtilement
incompatible avec ncurses. Tu dois donc recompiler ncurses, et là,
tu as intérêt de lier statiquement le ncurses à ton exécutable sous
peine de voir des choses amusantes dans les utilitaires du système
ou de coller la libncurses.so dans un répertoire spécifique à ton
application et demander à tes utilisateurs de lancer ton application
avec un LD_PRELOAD. Il n'y a pas que Linux dans la vie.
Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).
Un bug ponctuel, même si les développeurs traînent à le corriger (ce qui me
surprend, THomas Dickey m'ayant toujours semblé très réactif) n'invalide pas
un principe.
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures
cibles n'étaient pas vraiment une priorité.
Un autre exemple qui m'emmerde actuellement : j'ai une application
qui utilise à la fois la libpq du système (debian stable) et openssl
1.0.0. Regarde le résultat pour t'amuser
Ben c'est ta faute, tu mélanges les choses, tu cherches les ennuis. Utilise
openssl du système, la libpq du système sera compilée avec et tu n'auras pas
de soucis.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as
qu'à utiliser 0.9.8x ' ?
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Le 10 Aug 2010 08:39:41 GMT, Nicolas George <nicolas$ écrivait :
JKB wrote in message :
Il est quasiment impossible de trouver directement la bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible
Je ne comprends pas ce que tu veux dire par « trouver ». S'il s'agit de choisir les bons -I et -L pour avoir des versions cohérentes des bibliothèques, ce n'est pas le problème du développeur, c'est le problème de celui qui cherche à compiler un paquet sur un système incohérent.
C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses, mais un curses fourni par Sun^Oracle qui est subtilement incompatible avec ncurses. Tu dois donc recompiler ncurses, et là, tu as intérêt de lier statiquement le ncurses à ton exécutable sous peine de voir des choses amusantes dans les utilitaires du système ou de coller la libncurses.so dans un répertoire spécifique à ton application et demander à tes utilisateurs de lancer ton application avec un LD_PRELOAD. Il n'y a pas que Linux dans la vie.
Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).
Un bug ponctuel, même si les développeurs traînent à le corriger (ce qui me surprend, THomas Dickey m'ayant toujours semblé très réactif) n'invalide pas un principe.
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures cibles n'étaient pas vraiment une priorité.
Un autre exemple qui m'emmerde actuellement : j'ai une application qui utilise à la fois la libpq du système (debian stable) et openssl 1.0.0. Regarde le résultat pour t'amuser
Ben c'est ta faute, tu mélanges les choses, tu cherches les ennuis. Utilise openssl du système, la libpq du système sera compilée avec et tu n'auras pas de soucis.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as qu'à utiliser 0.9.8x ' ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours. => http://grincheux.de-charybde-en-scylla.fr
