grâce à quoi mes applications voient les fichiers gzippés comme s'ils ne
l'étaient pas. C'est très pratique mais, des fois, j'aimerais voir la
vraie taille de mes fichiers sans passer root. J'ai beau taper dans
konsole « unset LD_PRELOAD » cela n'a d'effet que pour les applications
lancées par la suite et depuis la même session konsole.
Existe-t-il un moyen d'étendre la portée de cet unset à toutes mes
applications, ou au moins à celles que je lance ensuite au moyen de liens
sur mon bureau ? Cette question a-t-elle un sens ?
Merci.
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
lhabert
geo cherchetout :
grâce à quoi mes applications voient les fichiers gzippés comme s'ils ne l'étaient pas.
Gasp! Mais quelle horreur!
Existe-t-il un moyen d'étendre la portée de cet unset à toutes mes applications, ou au moins à celles que je lance ensuite au moyen de liens sur mon bureau ?
Non.
Une solution consiste à te créer un symlink pointant en tant normal vers zlibc.so, et de mettre ce symlink dans ton LD_PRELOAD. Comme ça, tu n'as plus qu'à virer le symlink au moment de lancer un programme que tu veux sans zlibc.
geo cherchetout :
grâce à quoi mes applications voient les fichiers gzippés comme s'ils ne
l'étaient pas.
Gasp! Mais quelle horreur!
Existe-t-il un moyen d'étendre la portée de cet unset à toutes mes
applications, ou au moins à celles que je lance ensuite au moyen de liens
sur mon bureau ?
Non.
Une solution consiste à te créer un symlink pointant en tant normal vers
zlibc.so, et de mettre ce symlink dans ton LD_PRELOAD. Comme ça, tu n'as
plus qu'à virer le symlink au moment de lancer un programme que tu veux sans
zlibc.
grâce à quoi mes applications voient les fichiers gzippés comme s'ils ne l'étaient pas.
Gasp! Mais quelle horreur!
Existe-t-il un moyen d'étendre la portée de cet unset à toutes mes applications, ou au moins à celles que je lance ensuite au moyen de liens sur mon bureau ?
Non.
Une solution consiste à te créer un symlink pointant en tant normal vers zlibc.so, et de mettre ce symlink dans ton LD_PRELOAD. Comme ça, tu n'as plus qu'à virer le symlink au moment de lancer un programme que tu veux sans zlibc.
geo cherchetout
Le 29.12.2005 00:05, *Luc Habert* a écrit fort à propos :
grâce à quoi mes applications voient les fichiers gzippés comme s'ils ne l'étaient pas.
Gasp! Mais quelle horreur!
Pourquoi ? Je gagne beaucoup d'espace en gzippant une multitude de fichiers bmp qui alimentent une application Windows ne sachant utiliser que ce format. (Application que j'utilise avec Wine.)
Une solution consiste à te créer un symlink pointant en tant normal vers zlibc.so, et de mettre ce symlink dans ton LD_PRELOAD. Comme ça, tu n'as plus qu'à virer le symlink au moment de lancer un programme que tu veux sans zlibc.
La bibliothèque s'appelle uncompress.so. Je crée quelque part dans mon home un lien symbolique zlibc.so pointant vers /usr/local/lib/uncompress.so et je remplace dans mon .bash_profile LD_PRELOAD=/usr/local/lib/uncompress.so par LD_PRELOAD=/quelque_part/zlibc.so ? Je viens de le faire mais je ne pourrai essayer que vendredi. Le procédé me plaît et je le réutiliserai sûrement mais pourquoi l'action de renommer directement la bibliothèque est-elle sans effet sur certaines applications que je lance ensuite ? Par exemple, konqueror, lancé avec l'icône du tableau de bord, montre toujours les fichiers gzippés avec leur taille d'origine et sans l'extension gz alors que, comme attendu, mon application Windows ne sait plus ouvrir les mêmes fichiers gzippés. À bientôt, et merci.
Le 29.12.2005 00:05, *Luc Habert* a écrit fort à propos :
grâce à quoi mes applications voient les fichiers gzippés comme s'ils ne
l'étaient pas.
Gasp! Mais quelle horreur!
Pourquoi ? Je gagne beaucoup d'espace en gzippant une multitude de
fichiers bmp qui alimentent une application Windows ne sachant utiliser
que ce format. (Application que j'utilise avec Wine.)
Une solution consiste à te créer un symlink pointant en tant normal vers
zlibc.so, et de mettre ce symlink dans ton LD_PRELOAD. Comme ça, tu n'as
plus qu'à virer le symlink au moment de lancer un programme que tu veux sans
zlibc.
La bibliothèque s'appelle uncompress.so. Je crée quelque part dans mon
home un lien symbolique zlibc.so pointant vers
/usr/local/lib/uncompress.so et je remplace dans mon .bash_profile
LD_PRELOAD=/usr/local/lib/uncompress.so par
LD_PRELOAD=/quelque_part/zlibc.so ?
Je viens de le faire mais je ne pourrai essayer que vendredi.
Le procédé me plaît et je le réutiliserai sûrement mais pourquoi l'action
de renommer directement la bibliothèque est-elle sans effet sur certaines
applications que je lance ensuite ? Par exemple, konqueror, lancé avec
l'icône du tableau de bord, montre toujours les fichiers gzippés avec
leur taille d'origine et sans l'extension gz alors que, comme attendu,
mon application Windows ne sait plus ouvrir les mêmes fichiers gzippés.
À bientôt, et merci.
Le 29.12.2005 00:05, *Luc Habert* a écrit fort à propos :
grâce à quoi mes applications voient les fichiers gzippés comme s'ils ne l'étaient pas.
Gasp! Mais quelle horreur!
Pourquoi ? Je gagne beaucoup d'espace en gzippant une multitude de fichiers bmp qui alimentent une application Windows ne sachant utiliser que ce format. (Application que j'utilise avec Wine.)
Une solution consiste à te créer un symlink pointant en tant normal vers zlibc.so, et de mettre ce symlink dans ton LD_PRELOAD. Comme ça, tu n'as plus qu'à virer le symlink au moment de lancer un programme que tu veux sans zlibc.
La bibliothèque s'appelle uncompress.so. Je crée quelque part dans mon home un lien symbolique zlibc.so pointant vers /usr/local/lib/uncompress.so et je remplace dans mon .bash_profile LD_PRELOAD=/usr/local/lib/uncompress.so par LD_PRELOAD=/quelque_part/zlibc.so ? Je viens de le faire mais je ne pourrai essayer que vendredi. Le procédé me plaît et je le réutiliserai sûrement mais pourquoi l'action de renommer directement la bibliothèque est-elle sans effet sur certaines applications que je lance ensuite ? Par exemple, konqueror, lancé avec l'icône du tableau de bord, montre toujours les fichiers gzippés avec leur taille d'origine et sans l'extension gz alors que, comme attendu, mon application Windows ne sait plus ouvrir les mêmes fichiers gzippés. À bientôt, et merci.
lhabert
geo cherchetout :
La bibliothèque s'appelle uncompress.so. Je crée quelque part dans mon home un lien symbolique zlibc.so pointant vers /usr/local/lib/uncompress.so et je remplace dans mon .bash_profile LD_PRELOAD=/usr/local/lib/uncompress.so par LD_PRELOAD=/quelque_part/zlibc.so ?
Oui, c'est ça.
Le procédé me plaît et je le réutiliserai sûrement mais pourquoi l'action de renommer directement la bibliothèque est-elle sans effet sur certaines applications que je lance ensuite ? Par exemple, konqueror, lancé avec l'icône du tableau de bord, montre toujours les fichiers gzippés avec leur taille d'origine et sans l'extension gz alors que, comme attendu, mon application Windows ne sait plus ouvrir les mêmes fichiers gzippés.
Ah, ça c'est un hack de KDE. Comme KDE utilise beaucoup de libs dynamiques, un programme KDE prend pas mal de temps à se lancer juste à cause de l'initialisation des libs dynamiques. Ils optimisent ça en chargeant les DLLs une fois pour toutes dans le père de la session, et ensuite pour lancer un programme KDE, ce dernier se contente de forker sans faire d'exec (enfin j'ai jamais regardé comment ça marchait, mais je ne vois pas comment ça peut être fait autrement), résultat il garde toute la résolution des libs dynamiques faite au départ.
geo cherchetout :
La bibliothèque s'appelle uncompress.so. Je crée quelque part dans mon
home un lien symbolique zlibc.so pointant vers
/usr/local/lib/uncompress.so et je remplace dans mon .bash_profile
LD_PRELOAD=/usr/local/lib/uncompress.so par
LD_PRELOAD=/quelque_part/zlibc.so ?
Oui, c'est ça.
Le procédé me plaît et je le réutiliserai sûrement mais pourquoi l'action
de renommer directement la bibliothèque est-elle sans effet sur certaines
applications que je lance ensuite ? Par exemple, konqueror, lancé avec
l'icône du tableau de bord, montre toujours les fichiers gzippés avec
leur taille d'origine et sans l'extension gz alors que, comme attendu,
mon application Windows ne sait plus ouvrir les mêmes fichiers gzippés.
Ah, ça c'est un hack de KDE. Comme KDE utilise beaucoup de libs dynamiques,
un programme KDE prend pas mal de temps à se lancer juste à cause de
l'initialisation des libs dynamiques. Ils optimisent ça en chargeant les
DLLs une fois pour toutes dans le père de la session, et ensuite pour lancer
un programme KDE, ce dernier se contente de forker sans faire d'exec (enfin
j'ai jamais regardé comment ça marchait, mais je ne vois pas comment ça peut
être fait autrement), résultat il garde toute la résolution des libs
dynamiques faite au départ.
La bibliothèque s'appelle uncompress.so. Je crée quelque part dans mon home un lien symbolique zlibc.so pointant vers /usr/local/lib/uncompress.so et je remplace dans mon .bash_profile LD_PRELOAD=/usr/local/lib/uncompress.so par LD_PRELOAD=/quelque_part/zlibc.so ?
Oui, c'est ça.
Le procédé me plaît et je le réutiliserai sûrement mais pourquoi l'action de renommer directement la bibliothèque est-elle sans effet sur certaines applications que je lance ensuite ? Par exemple, konqueror, lancé avec l'icône du tableau de bord, montre toujours les fichiers gzippés avec leur taille d'origine et sans l'extension gz alors que, comme attendu, mon application Windows ne sait plus ouvrir les mêmes fichiers gzippés.
Ah, ça c'est un hack de KDE. Comme KDE utilise beaucoup de libs dynamiques, un programme KDE prend pas mal de temps à se lancer juste à cause de l'initialisation des libs dynamiques. Ils optimisent ça en chargeant les DLLs une fois pour toutes dans le père de la session, et ensuite pour lancer un programme KDE, ce dernier se contente de forker sans faire d'exec (enfin j'ai jamais regardé comment ça marchait, mais je ne vois pas comment ça peut être fait autrement), résultat il garde toute la résolution des libs dynamiques faite au départ.
lhabert
geo cherchetout :
Pourquoi ? Je gagne beaucoup d'espace en gzippant une multitude de fichiers bmp qui alimentent une application Windows ne sachant utiliser que ce format. (Application que j'utilise avec Wine.)
Bah je conteste pas que ça puisse être utile, mais c'est vraiment un hack crade, et, par conséquent, pas du tout robuste : si tu fais des trucs subtils à base de exec avec un fd pas rembobiné, ça va pas se comporter correctement. Avec les linux récents (noyau 2.6.14), il y a moyen de faire ça de façon robuste avec fuse.
geo cherchetout :
Pourquoi ? Je gagne beaucoup d'espace en gzippant une multitude de
fichiers bmp qui alimentent une application Windows ne sachant utiliser
que ce format. (Application que j'utilise avec Wine.)
Bah je conteste pas que ça puisse être utile, mais c'est vraiment un hack
crade, et, par conséquent, pas du tout robuste : si tu fais des trucs
subtils à base de exec avec un fd pas rembobiné, ça va pas se comporter
correctement. Avec les linux récents (noyau 2.6.14), il y a moyen de faire
ça de façon robuste avec fuse.
Pourquoi ? Je gagne beaucoup d'espace en gzippant une multitude de fichiers bmp qui alimentent une application Windows ne sachant utiliser que ce format. (Application que j'utilise avec Wine.)
Bah je conteste pas que ça puisse être utile, mais c'est vraiment un hack crade, et, par conséquent, pas du tout robuste : si tu fais des trucs subtils à base de exec avec un fd pas rembobiné, ça va pas se comporter correctement. Avec les linux récents (noyau 2.6.14), il y a moyen de faire ça de façon robuste avec fuse.
geo cherchetout
Le 29.12.2005 04:36, *Luc Habert* a écrit fort à propos :
Bah je conteste pas que ça puisse être utile, mais c'est vraiment un hack crade, et, par conséquent, pas du tout robuste : si tu fais des trucs subtils à base de exec avec un fd pas rembobiné, ça va pas se comporter correctement.
Je ne sais pas ce qu'est un fd ni comment ça se « rembobine » mais ta méfiance me semble digne de confiance. ;-)
Avec les linux récents (noyau 2.6.14), il y a moyen de faire ça de façon robuste avec fuse.
Ouah, mais ç'est sympathique ça!
$ uname -sr Linux 2.6.12-14mdk
et je vois que j'ai des choses dans /lib/modules/2.6.12-14mdk/kernel/3rdparty/fuse Je risque de revenir bientôt demander de l'aide à propos de fuse. À bientot et merci encore.
Le 29.12.2005 04:36, *Luc Habert* a écrit fort à propos :
Bah je conteste pas que ça puisse être utile, mais c'est vraiment un hack
crade, et, par conséquent, pas du tout robuste : si tu fais des trucs
subtils à base de exec avec un fd pas rembobiné, ça va pas se comporter
correctement.
Je ne sais pas ce qu'est un fd ni comment ça se « rembobine » mais ta
méfiance me semble digne de confiance. ;-)
Avec les linux récents (noyau 2.6.14), il y a moyen de faire
ça de façon robuste avec fuse.
Ouah, mais ç'est sympathique ça!
$ uname -sr
Linux 2.6.12-14mdk
et je vois que j'ai des choses dans
/lib/modules/2.6.12-14mdk/kernel/3rdparty/fuse
Je risque de revenir bientôt demander de l'aide à propos de fuse.
À bientot et merci encore.
Le 29.12.2005 04:36, *Luc Habert* a écrit fort à propos :
Bah je conteste pas que ça puisse être utile, mais c'est vraiment un hack crade, et, par conséquent, pas du tout robuste : si tu fais des trucs subtils à base de exec avec un fd pas rembobiné, ça va pas se comporter correctement.
Je ne sais pas ce qu'est un fd ni comment ça se « rembobine » mais ta méfiance me semble digne de confiance. ;-)
Avec les linux récents (noyau 2.6.14), il y a moyen de faire ça de façon robuste avec fuse.
Ouah, mais ç'est sympathique ça!
$ uname -sr Linux 2.6.12-14mdk
et je vois que j'ai des choses dans /lib/modules/2.6.12-14mdk/kernel/3rdparty/fuse Je risque de revenir bientôt demander de l'aide à propos de fuse. À bientot et merci encore.
geo cherchetout
Pour utiliser zlibc, (sous Mandriva 2006) j'ai ajouté dans mon fichier .bash_profile les lignes suivantes :
J'ai peut-être trouvé une meilleure solution, trop évidente pour qu'on ait osé me l'indiquer : Ne rien ajouter dans bash_profile mais lancer les applications qui ont besoin de zlibc avec : export LD_PRELOAD=/usr/local/lib/uncompress.so; application arguments
Des objections ?
Pour utiliser zlibc, (sous Mandriva 2006) j'ai ajouté dans mon fichier
.bash_profile les lignes suivantes :
J'ai peut-être trouvé une meilleure solution, trop évidente pour qu'on
ait osé me l'indiquer : Ne rien ajouter dans bash_profile mais lancer les
applications qui ont besoin de zlibc avec :
export LD_PRELOAD=/usr/local/lib/uncompress.so; application arguments
J'ai peut-être trouvé une meilleure solution, trop évidente pour qu'on ait osé me l'indiquer : Ne rien ajouter dans bash_profile mais lancer les applications qui ont besoin de zlibc avec : export LD_PRELOAD=/usr/local/lib/uncompress.so; application arguments
Il est vrai que je fréquente beaucoup plus de newsgroups libres que de newsgroups usenet. mouarf ;-)))) c'est beau d'assister à la naissance d'un troll bien velu
Il est vrai que je fréquente beaucoup plus de newsgroups libres
que de newsgroups usenet.
mouarf ;-)))) c'est beau d'assister à la naissance d'un troll bien velu
Il est vrai que je fréquente beaucoup plus de newsgroups libres que de newsgroups usenet. mouarf ;-)))) c'est beau d'assister à la naissance d'un troll bien velu
--{ Eric, dans fr.comp.lang.python }--
bof
geo cherchetout wrote:
Bonjour, Pour utiliser zlibc, (sous Mandriva 2006) j'ai ajouté dans mon fichier .bash_profile les lignes suivantes :
