librairie
Or, en ce qui me concerne cela m'empeche d'utiliser ma librairie (je ne
dispose pas des sources).
Auriez-vous déjà eu ce problème, et si oui comment l'avez-vous résolu.
librairie
Or, en ce qui me concerne cela m'empeche d'utiliser ma librairie (je ne
dispose pas des sources).
Auriez-vous déjà eu ce problème, et si oui comment l'avez-vous résolu.
librairie
Or, en ce qui me concerne cela m'empeche d'utiliser ma librairie (je ne
dispose pas des sources).
Auriez-vous déjà eu ce problème, et si oui comment l'avez-vous résolu.
"Seb" , dans le message <br43tq$qui$, alibrairie
Le mot que tu cherches est « bibliothèque ».
Or, en ce qui me concerne cela m'empeche d'utiliser ma librairie (je
ne dispose pas des sources).
C'est bête, hein, les programmes propriétaires ?
Auriez-vous déjà eu ce problème, et si oui comment l'avez-vous
résolu.
Il ne devrait pas y avoir de problème de compatibilité avec la glibc,
grace au ELF symbol versionning. J'ai ici une glibc 2.3.2, et elle a
bien le symbole __ctype_b estampillé GLIBC_2.0. Un examen de celle de
la RedHat montre le même symbole, mais avec des attributs légèrement
différents, d'une manière que je ne sais pas lire. Tu peux essayer de
recompiler une glibc, l'installer dans un coin et jouer avec
LD_LIBRARY_PATH.
"Seb" , dans le message <br43tq$qui$1@s1.read.news.oleane.net>, a
librairie
Le mot que tu cherches est « bibliothèque ».
Or, en ce qui me concerne cela m'empeche d'utiliser ma librairie (je
ne dispose pas des sources).
C'est bête, hein, les programmes propriétaires ?
Auriez-vous déjà eu ce problème, et si oui comment l'avez-vous
résolu.
Il ne devrait pas y avoir de problème de compatibilité avec la glibc,
grace au ELF symbol versionning. J'ai ici une glibc 2.3.2, et elle a
bien le symbole __ctype_b estampillé GLIBC_2.0. Un examen de celle de
la RedHat montre le même symbole, mais avec des attributs légèrement
différents, d'une manière que je ne sais pas lire. Tu peux essayer de
recompiler une glibc, l'installer dans un coin et jouer avec
LD_LIBRARY_PATH.
"Seb" , dans le message <br43tq$qui$, alibrairie
Le mot que tu cherches est « bibliothèque ».
Or, en ce qui me concerne cela m'empeche d'utiliser ma librairie (je
ne dispose pas des sources).
C'est bête, hein, les programmes propriétaires ?
Auriez-vous déjà eu ce problème, et si oui comment l'avez-vous
résolu.
Il ne devrait pas y avoir de problème de compatibilité avec la glibc,
grace au ELF symbol versionning. J'ai ici une glibc 2.3.2, et elle a
bien le symbole __ctype_b estampillé GLIBC_2.0. Un examen de celle de
la RedHat montre le même symbole, mais avec des attributs légèrement
différents, d'une manière que je ne sais pas lire. Tu peux essayer de
recompiler une glibc, l'installer dans un coin et jouer avec
LD_LIBRARY_PATH.
J'ai regardé bugzilla, et il semble que red hat ait changé "__ctype_b" pour
"__ctype_b_loc" (j'ai pas trop compris les raisons). Je ne sais pas trop ce
qu'est ELF,
mais au vue des anomalies qui ont été postées par rapport à ce
symbole, il est clair que Red Hat a renommé ce symbole.
Je vais essayer de recompiler ma glibc : si tu pouvais m'indiquer comment
procéder se serait sympa, sinon Mr Google;
J'ai regardé bugzilla, et il semble que red hat ait changé "__ctype_b" pour
"__ctype_b_loc" (j'ai pas trop compris les raisons). Je ne sais pas trop ce
qu'est ELF,
mais au vue des anomalies qui ont été postées par rapport à ce
symbole, il est clair que Red Hat a renommé ce symbole.
Je vais essayer de recompiler ma glibc : si tu pouvais m'indiquer comment
procéder se serait sympa, sinon Mr Google;
J'ai regardé bugzilla, et il semble que red hat ait changé "__ctype_b" pour
"__ctype_b_loc" (j'ai pas trop compris les raisons). Je ne sais pas trop ce
qu'est ELF,
mais au vue des anomalies qui ont été postées par rapport à ce
symbole, il est clair que Red Hat a renommé ce symbole.
Je vais essayer de recompiler ma glibc : si tu pouvais m'indiquer comment
procéder se serait sympa, sinon Mr Google;
"Seb" , dans le message <br4n11$80t$, aJ'ai regardé bugzilla, et il semble que red hat ait changé
"__ctype_b" pour "__ctype_b_loc" (j'ai pas trop compris les
raisons). Je ne sais pas trop ce qu'est ELF,
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format. Si
je récupère sur un FreeBSD la libc (include et .so), que j'utilise un
gcc
natif Linux avec les bonnes options, je peux obtenir un binaire
FreeBSD
qui marchera parfaitement. Tant que c'est compilé pour le même
processeur évidemment.
Le symbol versionning, c'est la possibilité de mettre plusieurs fois
le
même symbole, avec des versions différentes, dans la bibliothèque.
mais au vue des anomalies qui ont été postées par rapport à ce
symbole, il est clair que Red Hat a renommé ce symbole.
Voici ce que j'obtiens sur une glibc RedHat 2.3.2-11 fraîchement
téléchargée :
/tmp $ objdump -T lib/libc-2.3.2.so | grep
__ctype_b 00020eec g DF .text 0000006a GLIBC_2.3 __ctype_b_loc
0011f938 g DO .data 00000004 (GLIBC_2.0) __ctype_b
Sur ma Debian Sarge (glibc 2.3.2 aussi), j'ai ceci :
~ $ objdump -T /lib/libc-2.3.2.so | grep __ctype_b
00128498 g DO .data 00000004 GLIBC_2.0 __ctype_b
00023650 g DF .text 00000071 GLIBC_2.3 __ctype_b_loc
Donc il y a bien un nouveau symbole __ctype_b_loc, mais l'ancien,
__ctype_b, est toujours là, mais pas de la même manière entre les
deux.
Je vais essayer de recompiler ma glibc : si tu pouvais m'indiquer
comment procéder se serait sympa, sinon Mr Google;
Il y a plus simple, en fait : récupérer la libc d'une autre distrib.
Au fait, quel est le débat ?
"Seb" , dans le message <br4n11$80t$1@s1.read.news.oleane.net>, a
J'ai regardé bugzilla, et il semble que red hat ait changé
"__ctype_b" pour "__ctype_b_loc" (j'ai pas trop compris les
raisons). Je ne sais pas trop ce qu'est ELF,
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format. Si
je récupère sur un FreeBSD la libc (include et .so), que j'utilise un
gcc
natif Linux avec les bonnes options, je peux obtenir un binaire
FreeBSD
qui marchera parfaitement. Tant que c'est compilé pour le même
processeur évidemment.
Le symbol versionning, c'est la possibilité de mettre plusieurs fois
le
même symbole, avec des versions différentes, dans la bibliothèque.
mais au vue des anomalies qui ont été postées par rapport à ce
symbole, il est clair que Red Hat a renommé ce symbole.
Voici ce que j'obtiens sur une glibc RedHat 2.3.2-11 fraîchement
téléchargée :
george@quatramaran /tmp $ objdump -T lib/libc-2.3.2.so | grep
__ctype_b 00020eec g DF .text 0000006a GLIBC_2.3 __ctype_b_loc
0011f938 g DO .data 00000004 (GLIBC_2.0) __ctype_b
Sur ma Debian Sarge (glibc 2.3.2 aussi), j'ai ceci :
cigaes@ssecem ~ $ objdump -T /lib/libc-2.3.2.so | grep __ctype_b
00128498 g DO .data 00000004 GLIBC_2.0 __ctype_b
00023650 g DF .text 00000071 GLIBC_2.3 __ctype_b_loc
Donc il y a bien un nouveau symbole __ctype_b_loc, mais l'ancien,
__ctype_b, est toujours là, mais pas de la même manière entre les
deux.
Je vais essayer de recompiler ma glibc : si tu pouvais m'indiquer
comment procéder se serait sympa, sinon Mr Google;
Il y a plus simple, en fait : récupérer la libc d'une autre distrib.
Au fait, quel est le débat ?
"Seb" , dans le message <br4n11$80t$, aJ'ai regardé bugzilla, et il semble que red hat ait changé
"__ctype_b" pour "__ctype_b_loc" (j'ai pas trop compris les
raisons). Je ne sais pas trop ce qu'est ELF,
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format. Si
je récupère sur un FreeBSD la libc (include et .so), que j'utilise un
gcc
natif Linux avec les bonnes options, je peux obtenir un binaire
FreeBSD
qui marchera parfaitement. Tant que c'est compilé pour le même
processeur évidemment.
Le symbol versionning, c'est la possibilité de mettre plusieurs fois
le
même symbole, avec des versions différentes, dans la bibliothèque.
mais au vue des anomalies qui ont été postées par rapport à ce
symbole, il est clair que Red Hat a renommé ce symbole.
Voici ce que j'obtiens sur une glibc RedHat 2.3.2-11 fraîchement
téléchargée :
/tmp $ objdump -T lib/libc-2.3.2.so | grep
__ctype_b 00020eec g DF .text 0000006a GLIBC_2.3 __ctype_b_loc
0011f938 g DO .data 00000004 (GLIBC_2.0) __ctype_b
Sur ma Debian Sarge (glibc 2.3.2 aussi), j'ai ceci :
~ $ objdump -T /lib/libc-2.3.2.so | grep __ctype_b
00128498 g DO .data 00000004 GLIBC_2.0 __ctype_b
00023650 g DF .text 00000071 GLIBC_2.3 __ctype_b_loc
Donc il y a bien un nouveau symbole __ctype_b_loc, mais l'ancien,
__ctype_b, est toujours là, mais pas de la même manière entre les
deux.
Je vais essayer de recompiler ma glibc : si tu pouvais m'indiquer
comment procéder se serait sympa, sinon Mr Google;
Il y a plus simple, en fait : récupérer la libc d'une autre distrib.
Au fait, quel est le débat ?
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format. Si je
récupère sur un FreeBSD la libc (include et .so), que j'utilise un gcc
natif Linux avec les bonnes options, je peux obtenir un binaire FreeBSD
qui marchera parfaitement. Tant que c'est compilé pour le même
processeur évidemment.
Le symbol versionning, c'est la possibilité de mettre plusieurs fois le
même symbole, avec des versions différentes, dans la bibliothèque.
Au fait, quel est le débat ?
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format. Si je
récupère sur un FreeBSD la libc (include et .so), que j'utilise un gcc
natif Linux avec les bonnes options, je peux obtenir un binaire FreeBSD
qui marchera parfaitement. Tant que c'est compilé pour le même
processeur évidemment.
Le symbol versionning, c'est la possibilité de mettre plusieurs fois le
même symbole, avec des versions différentes, dans la bibliothèque.
Au fait, quel est le débat ?
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format. Si je
récupère sur un FreeBSD la libc (include et .so), que j'utilise un gcc
natif Linux avec les bonnes options, je peux obtenir un binaire FreeBSD
qui marchera parfaitement. Tant que c'est compilé pour le même
processeur évidemment.
Le symbol versionning, c'est la possibilité de mettre plusieurs fois le
même symbole, avec des versions différentes, dans la bibliothèque.
Au fait, quel est le débat ?
Depuis peu ? Ça dépend des plate-formes (-:
Ça n'a rien à voir avec gcc,
Et ça, c'est une extension à ELF qui n'est pas nécessairement supportée
partout (en fait, nulle part ailleurs que sous Linux et Hurd, pour
autant que je sache...)
Depuis peu ? Ça dépend des plate-formes (-:
Ça n'a rien à voir avec gcc,
Et ça, c'est une extension à ELF qui n'est pas nécessairement supportée
partout (en fait, nulle part ailleurs que sous Linux et Hurd, pour
autant que je sache...)
Depuis peu ? Ça dépend des plate-formes (-:
Ça n'a rien à voir avec gcc,
Et ça, c'est une extension à ELF qui n'est pas nécessairement supportée
partout (en fait, nulle part ailleurs que sous Linux et Hurd, pour
autant que je sache...)
"Seb" , dans le message <br4n11$80t$, a
écrit :J'ai regardé bugzilla, et il semble que red hat ait changé "__ctype_b" pour
"__ctype_b_loc" (j'ai pas trop compris les raisons). Je ne sais pas trop ce
qu'est ELF,
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format.
"Seb" , dans le message <br4n11$80t$1@s1.read.news.oleane.net>, a
écrit :
J'ai regardé bugzilla, et il semble que red hat ait changé "__ctype_b" pour
"__ctype_b_loc" (j'ai pas trop compris les raisons). Je ne sais pas trop ce
qu'est ELF,
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format.
"Seb" , dans le message <br4n11$80t$, a
écrit :J'ai regardé bugzilla, et il semble que red hat ait changé "__ctype_b" pour
"__ctype_b_loc" (j'ai pas trop compris les raisons). Je ne sais pas trop ce
qu'est ELF,
ELF est la norme des exécutables sous beaucoup d'Unix, dont Linux,
Solaris, FreeBSD et depuis peu OpenBSD. C'est bien le même format.
