Je viens de passer de FreeBSD 5.2.1 à 5.3 via cvsup sur /usr/src.
À la lecture de /usr/src/UPDATING (mais aussi suite à des bugs de compilation
de gnome 2.8), j'ai recompilé tous les ports qui dépendaient de libm.so.2 pour
qu'ils utilisent libm.so.3.
J'ai voulu faire la même chose pour ceux qui dépendaient de libc_r.so (afin
qu'ils utilisent libthread.so). Mais, pour certains, la recompilation n'y fait
rien. Ils continuent à utiliser libc_r.so. J'ai donc opté pour la création du
fichier /etc/libmap.conf adéquat (celui qui est donné en exemple dans le page
de man - à croire que libmap.conf n'a été créé que pour ça).
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
- Est-ce à celui qui crée le port de changer l'utilisation de libc_r par celle
de libthread ?
- Quelles conséquence(s) (éventuellement néfaste(s)) peut avoir la mise en
place de ce fichier libmap.conf ?
Merci.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
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
Paul Gaborit
À (at) Mon, 15 Nov 2004 17:08:49 +0100, j'écrivais :
Je viens de passer de FreeBSD 5.2.1 à 5.3 via cvsup sur /usr/src.
À la lecture de /usr/src/UPDATING (mais aussi suite à des bugs de compilation de gnome 2.8), j'ai recompilé tous les ports qui dépendaient de libm.so.2 pour qu'ils utilisent libm.so.3.
J'ai voulu faire la même chose pour ceux qui dépendaient de libc_r.so (afin qu'ils utilisent libthread.so).
(je voulais écrire libpthread.so)
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à utiliser libc_r.so. J'ai donc opté pour la création du fichier /etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de man - à croire que libmap.conf n'a été créé que pour ça).
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
- Est-ce à celui qui crée le port de changer l'utilisation de libc_r par celle de libthread ?
(idem)
- Quelles conséquence(s) (éventuellement néfaste(s)) peut avoir la mise en place de ce fichier libmap.conf ?
Mes questions sont peut-être bêtes... mais elles restent sans réponses.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Mon, 15 Nov 2004 17:08:49 +0100,
j'écrivais :
Je viens de passer de FreeBSD 5.2.1 à 5.3 via cvsup sur /usr/src.
À la lecture de /usr/src/UPDATING (mais aussi suite à des bugs de
compilation de gnome 2.8), j'ai recompilé tous les ports qui dépendaient de
libm.so.2 pour qu'ils utilisent libm.so.3.
J'ai voulu faire la même chose pour ceux qui dépendaient de libc_r.so (afin
qu'ils utilisent libthread.so).
(je voulais écrire libpthread.so)
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à
utiliser libc_r.so. J'ai donc opté pour la création du fichier
/etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de man
- à croire que libmap.conf n'a été créé que pour ça).
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
- Est-ce à celui qui crée le port de changer l'utilisation de libc_r par
celle de libthread ?
(idem)
- Quelles conséquence(s) (éventuellement néfaste(s)) peut avoir la mise en
place de ce fichier libmap.conf ?
Mes questions sont peut-être bêtes... mais elles restent sans réponses.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Mon, 15 Nov 2004 17:08:49 +0100, j'écrivais :
Je viens de passer de FreeBSD 5.2.1 à 5.3 via cvsup sur /usr/src.
À la lecture de /usr/src/UPDATING (mais aussi suite à des bugs de compilation de gnome 2.8), j'ai recompilé tous les ports qui dépendaient de libm.so.2 pour qu'ils utilisent libm.so.3.
J'ai voulu faire la même chose pour ceux qui dépendaient de libc_r.so (afin qu'ils utilisent libthread.so).
(je voulais écrire libpthread.so)
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à utiliser libc_r.so. J'ai donc opté pour la création du fichier /etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de man - à croire que libmap.conf n'a été créé que pour ça).
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
- Est-ce à celui qui crée le port de changer l'utilisation de libc_r par celle de libthread ?
(idem)
- Quelles conséquence(s) (éventuellement néfaste(s)) peut avoir la mise en place de ce fichier libmap.conf ?
Mes questions sont peut-être bêtes... mais elles restent sans réponses.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Thierry Thomas
Mardi 16 novembre 2004 à 13:39 GMT, Paul Gaborit a écrit :
J'ai voulu faire la même chose pour ceux qui dépendaient de libc_r.so (afin qu'ils utilisent libthread.so).
(je voulais écrire libpthread.so)
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à utiliser libc_r.so. J'ai donc opté pour la création du fichier /etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de man - à croire que libmap.conf n'a été créé que pour ça).
Par curiosité, quels ports sont concernés ?
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
Ben oui, c'est l'entrée 20040303 de /usr/src/UPDATING et c'est fait pour ça. Mais ce n'est qu'une mesure transitoire, et il serait préférable de s'en débarasser. Il y a d'ailleurs l'entrée #NOLIBC_R= true # do not build libc_r (re-entrant version of libc) dans /etc/defaults/make.conf que l'on peut dé-commenter et ajouter à /etc/make.conf. (pas encore essayé...) -- Th. Thomas.
Mardi 16 novembre 2004 à 13:39 GMT, Paul Gaborit a écrit :
J'ai voulu faire la même chose pour ceux qui dépendaient de libc_r.so (afin
qu'ils utilisent libthread.so).
(je voulais écrire libpthread.so)
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à
utiliser libc_r.so. J'ai donc opté pour la création du fichier
/etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de man
- à croire que libmap.conf n'a été créé que pour ça).
Par curiosité, quels ports sont concernés ?
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
Ben oui, c'est l'entrée 20040303 de /usr/src/UPDATING et c'est fait pour
ça. Mais ce n'est qu'une mesure transitoire, et il serait préférable de
s'en débarasser. Il y a d'ailleurs l'entrée
#NOLIBC_R= true # do not build libc_r (re-entrant version of libc)
dans /etc/defaults/make.conf que l'on peut dé-commenter et ajouter à
/etc/make.conf. (pas encore essayé...)
--
Th. Thomas.
Mardi 16 novembre 2004 à 13:39 GMT, Paul Gaborit a écrit :
J'ai voulu faire la même chose pour ceux qui dépendaient de libc_r.so (afin qu'ils utilisent libthread.so).
(je voulais écrire libpthread.so)
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à utiliser libc_r.so. J'ai donc opté pour la création du fichier /etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de man - à croire que libmap.conf n'a été créé que pour ça).
Par curiosité, quels ports sont concernés ?
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
Ben oui, c'est l'entrée 20040303 de /usr/src/UPDATING et c'est fait pour ça. Mais ce n'est qu'une mesure transitoire, et il serait préférable de s'en débarasser. Il y a d'ailleurs l'entrée #NOLIBC_R= true # do not build libc_r (re-entrant version of libc) dans /etc/defaults/make.conf que l'on peut dé-commenter et ajouter à /etc/make.conf. (pas encore essayé...) -- Th. Thomas.
Paul Gaborit
À (at) Tue, 16 Nov 2004 18:14:39 +0000 (UTC), Thierry Thomas écrivait (wrote):
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à utiliser libc_r.so. J'ai donc opté pour la création du fichier /etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de man - à croire que libmap.conf n'a été créé que pour ça).
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
Ben oui, c'est l'entrée 20040303 de /usr/src/UPDATING et c'est fait pour ça. Mais ce n'est qu'une mesure transitoire, et il serait préférable de s'en débarasser. Il y a d'ailleurs l'entrée #NOLIBC_R= true # do not build libc_r (re-entrant version of libc) dans /etc/defaults/make.conf que l'on peut dé-commenter et ajouter à /etc/make.conf. (pas encore essayé...)
Ah oui. J'avais raté cette option. Ceci étant, si un port demande explicitement un lien vers libc_r et si on place cette option, il faut obligatoirement remappé libc_r vers libpthread via libmap pour que ça marche.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 16 Nov 2004 18:14:39 +0000 (UTC),
Thierry Thomas <tthomas@mail.dotcom.fr> écrivait (wrote):
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à
utiliser libc_r.so. J'ai donc opté pour la création du fichier
/etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de
man - à croire que libmap.conf n'a été créé que pour ça).
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais
environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner
mon petit programme de test pour les retrouver.
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
Ben oui, c'est l'entrée 20040303 de /usr/src/UPDATING et c'est fait pour
ça. Mais ce n'est qu'une mesure transitoire, et il serait préférable de
s'en débarasser. Il y a d'ailleurs l'entrée
#NOLIBC_R= true # do not build libc_r (re-entrant version of libc)
dans /etc/defaults/make.conf que l'on peut dé-commenter et ajouter à
/etc/make.conf. (pas encore essayé...)
Ah oui. J'avais raté cette option. Ceci étant, si un port demande
explicitement un lien vers libc_r et si on place cette option, il faut
obligatoirement remappé libc_r vers libpthread via libmap pour que ça marche.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 16 Nov 2004 18:14:39 +0000 (UTC), Thierry Thomas écrivait (wrote):
Mais, pour certains, la recompilation n'y fait rien. Ils continuent à utiliser libc_r.so. J'ai donc opté pour la création du fichier /etc/libmap.conf adéquat (celui qui est donné en exemple dans le page de man - à croire que libmap.conf n'a été créé que pour ça).
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
- Ai-je bien fait ? (en fait, oui... puisque ça marche ;-) )
Ben oui, c'est l'entrée 20040303 de /usr/src/UPDATING et c'est fait pour ça. Mais ce n'est qu'une mesure transitoire, et il serait préférable de s'en débarasser. Il y a d'ailleurs l'entrée #NOLIBC_R= true # do not build libc_r (re-entrant version of libc) dans /etc/defaults/make.conf que l'on peut dé-commenter et ajouter à /etc/make.conf. (pas encore essayé...)
Ah oui. J'avais raté cette option. Ceci étant, si un port demande explicitement un lien vers libc_r et si on place cette option, il faut obligatoirement remappé libc_r vers libpthread via libmap pour que ça marche.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Thierry Thomas
Mercredi 17 novembre 2004 à 12:29 GMT, Paul Gaborit a écrit :
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide pour voir quelle bibliothèque ils prendront. -- Th. Thomas.
Mercredi 17 novembre 2004 à 12:29 GMT, Paul Gaborit a écrit :
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais
environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner
mon petit programme de test pour les retrouver.
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide
pour voir quelle bibliothèque ils prendront.
--
Th. Thomas.
Mercredi 17 novembre 2004 à 12:29 GMT, Paul Gaborit a écrit :
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide pour voir quelle bibliothèque ils prendront. -- Th. Thomas.
Paul Gaborit
À (at) Wed, 17 Nov 2004 21:24:44 +0000 (UTC), Thierry Thomas écrivait (wrote):
Mercredi 17 novembre 2004 à 12:29 GMT, Paul Gaborit a écrit :
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide pour voir quelle bibliothèque ils prendront.
Ok. Je fais la liste ce soir.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Wed, 17 Nov 2004 21:24:44 +0000 (UTC),
Thierry Thomas <tthomas@mail.dotcom.fr> écrivait (wrote):
Mercredi 17 novembre 2004 à 12:29 GMT, Paul Gaborit a écrit :
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais
environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire
tourner mon petit programme de test pour les retrouver.
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide pour
voir quelle bibliothèque ils prendront.
Ok. Je fais la liste ce soir.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Wed, 17 Nov 2004 21:24:44 +0000 (UTC), Thierry Thomas écrivait (wrote):
Mercredi 17 novembre 2004 à 12:29 GMT, Paul Gaborit a écrit :
Par curiosité, quels ports sont concernés ?
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide pour voir quelle bibliothèque ils prendront.
Ok. Je fais la liste ce soir.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Marwan Burelle
On Wed, 17 Nov 2004 13:29:40 +0100 Paul Gaborit wrote:
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
On peut pas faire ça avec sysutil/libchk ?
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Wed, 17 Nov 2004 13:29:40 +0100
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Ils étaient nombreux (parmi les 400 ports installés chez moi, je
dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux
refaire tourner mon petit programme de test pour les retrouver.
On peut pas faire ça avec sysutil/libchk ?
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On Wed, 17 Nov 2004 13:29:40 +0100 Paul Gaborit wrote:
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
On peut pas faire ça avec sysutil/libchk ?
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Paul Gaborit
À (at) Fri, 19 Nov 2004 11:51:08 +0100, Marwan Burelle écrivait (wrote):
On Wed, 17 Nov 2004 13:29:40 +0100 Paul Gaborit wrote:
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
On peut pas faire ça avec sysutil/libchk ?
Je ne sais pas (je ne connais pas ce port). Je vais y jeter un oeil.
Mon petit script est très simple : pour tous les exécutables et bilbliothèques dynamiques, il regarde la sortie de 'ldd -v' pour identifier ce qui fait appel à libm.so.2 (ça peut-être la programme lui-même ou l'une de ses parties dynamiques) puis après j'appelle pkg_which pour chacun des trucs qui dépend de libm.so.2.
Cette méthode peut évidemment s'appliquer à d'autres bibliothèques (libc_r.so dans le cas qui nous intéresse).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Fri, 19 Nov 2004 11:51:08 +0100,
Marwan Burelle <burelle@lri.fr> écrivait (wrote):
On Wed, 17 Nov 2004 13:29:40 +0100
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Ils étaient nombreux (parmi les 400 ports installés chez moi, je
dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux
refaire tourner mon petit programme de test pour les retrouver.
On peut pas faire ça avec sysutil/libchk ?
Je ne sais pas (je ne connais pas ce port). Je vais y jeter un oeil.
Mon petit script est très simple : pour tous les exécutables et bilbliothèques
dynamiques, il regarde la sortie de 'ldd -v' pour identifier ce qui fait appel
à libm.so.2 (ça peut-être la programme lui-même ou l'une de ses parties
dynamiques) puis après j'appelle pkg_which pour chacun des trucs qui dépend de
libm.so.2.
Cette méthode peut évidemment s'appliquer à d'autres bibliothèques (libc_r.so
dans le cas qui nous intéresse).
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Fri, 19 Nov 2004 11:51:08 +0100, Marwan Burelle écrivait (wrote):
On Wed, 17 Nov 2004 13:29:40 +0100 Paul Gaborit wrote:
Ils étaient nombreux (parmi les 400 ports installés chez moi, je dirais environ un vingtaine). Si vous le souhaitez, ce soir je peux refaire tourner mon petit programme de test pour les retrouver.
On peut pas faire ça avec sysutil/libchk ?
Je ne sais pas (je ne connais pas ce port). Je vais y jeter un oeil.
Mon petit script est très simple : pour tous les exécutables et bilbliothèques dynamiques, il regarde la sortie de 'ldd -v' pour identifier ce qui fait appel à libm.so.2 (ça peut-être la programme lui-même ou l'une de ses parties dynamiques) puis après j'appelle pkg_which pour chacun des trucs qui dépend de libm.so.2.
Cette méthode peut évidemment s'appliquer à d'autres bibliothèques (libc_r.so dans le cas qui nous intéresse).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) Wed, 17 Nov 2004 21:24:44 +0000 (UTC), Thierry Thomas écrivait (wrote):
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide pour voir quelle bibliothèque ils prendront.
Je répondais :
Ok. Je fais la liste ce soir.
Vous avez bien fait d'insister.
La liste que j'ai obtenu comportait une majorité de ports liés à gnome... Par exemple : glib et linc. Et, effectivement, une recompilation de linc produisait toujours un bibliothèque liblinc.so qui dépendait directement de libc_r.so (ainsi que de libgthread-2.0.so.400). Mais en recompilant glib puis linc, cette dépendance disparait.
Je vais donc recompiler les quelques ports concernés dans leur ordre de dépendances et tout devrait rentrer dans l'ordre.
Merci.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Wed, 17 Nov 2004 21:24:44 +0000 (UTC),
Thierry Thomas <tthomas@mail.dotcom.fr> écrivait (wrote):
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide
pour voir quelle bibliothèque ils prendront.
Je répondais :
Ok. Je fais la liste ce soir.
Vous avez bien fait d'insister.
La liste que j'ai obtenu comportait une majorité de ports liés à gnome... Par
exemple : glib et linc. Et, effectivement, une recompilation de linc
produisait toujours un bibliothèque liblinc.so qui dépendait directement de
libc_r.so (ainsi que de libgthread-2.0.so.400). Mais en recompilant glib puis
linc, cette dépendance disparait.
Je vais donc recompiler les quelques ports concernés dans leur ordre de
dépendances et tout devrait rentrer dans l'ordre.
Merci.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Wed, 17 Nov 2004 21:24:44 +0000 (UTC), Thierry Thomas écrivait (wrote):
Je veux bien, ça m'intéresserait de les reconstruire dans une jail vide pour voir quelle bibliothèque ils prendront.
Je répondais :
Ok. Je fais la liste ce soir.
Vous avez bien fait d'insister.
La liste que j'ai obtenu comportait une majorité de ports liés à gnome... Par exemple : glib et linc. Et, effectivement, une recompilation de linc produisait toujours un bibliothèque liblinc.so qui dépendait directement de libc_r.so (ainsi que de libgthread-2.0.so.400). Mais en recompilant glib puis linc, cette dépendance disparait.
Je vais donc recompiler les quelques ports concernés dans leur ordre de dépendances et tout devrait rentrer dans l'ordre.
Merci.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) Fri, 19 Nov 2004 13:47:32 +0100, Paul Gaborit écrivait (wrote):
À (at) Fri, 19 Nov 2004 11:51:08 +0100, Marwan Burelle écrivait (wrote):
On peut pas faire ça avec sysutil/libchk ?
En fait, libchk n'est pas vraiment conçu pour ça. Peut-être en définissant la variable d'environnement LD_LIBMAP_DISABLE et en déplaçant momentanément libc_r.so. Je n'ai pas essayé...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Fri, 19 Nov 2004 13:47:32 +0100,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
À (at) Fri, 19 Nov 2004 11:51:08 +0100,
Marwan Burelle <burelle@lri.fr> écrivait (wrote):
On peut pas faire ça avec sysutil/libchk ?
En fait, libchk n'est pas vraiment conçu pour ça. Peut-être en définissant la
variable d'environnement LD_LIBMAP_DISABLE et en déplaçant momentanément
libc_r.so. Je n'ai pas essayé...
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Fri, 19 Nov 2004 13:47:32 +0100, Paul Gaborit écrivait (wrote):
À (at) Fri, 19 Nov 2004 11:51:08 +0100, Marwan Burelle écrivait (wrote):
On peut pas faire ça avec sysutil/libchk ?
En fait, libchk n'est pas vraiment conçu pour ça. Peut-être en définissant la variable d'environnement LD_LIBMAP_DISABLE et en déplaçant momentanément libc_r.so. Je n'ai pas essayé...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
