É> Quelle belle connerie que cette définition d'unix ! Mac OS X gère les É> bibliothèques dynamiques d'une autre façon que les unix utilisant ELF. Et É> alors ?
Essayez de les utiliser
--
Guy Decoux
"É" == Éric Lévénez <eric@levenez.com> writes:
On prévient quand on change les groupes
É> Quelle belle connerie que cette définition d'unix ! Mac OS X gère les
É> bibliothèques dynamiques d'une autre façon que les unix utilisant ELF. Et
É> alors ?
É> Quelle belle connerie que cette définition d'unix ! Mac OS X gère les É> bibliothèques dynamiques d'une autre façon que les unix utilisant ELF. Et É> alors ?
Essayez de les utiliser
--
Guy Decoux
Éric Lévénez
Le 20/07/03 15:18, dans , « ts » a écrit :
"É" == Éric Lévénez writes:
On prévient quand on change les groupes
É> Quelle belle connerie que cette définition d'unix ! Mac OS X gère les É> bibliothèques dynamiques d'une autre façon que les unix utilisant ELF. Et É> alors ?
Essayez de les utiliser
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement lier des fonctions alors que la façon ELF bride à fond ce type de comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais? As-tu regarder ce que permettait xcode en matière de comportement dynamique. Dyld permet aussi de gérer finement les versions, ce que ne permet pas les implémentations "traditionnelles" ELF, c'est mal ?
C'est quand même stupéfiant que certains considèrent que ELF est la base d'unix ! Je pense que certains considèrent même que X Window System est requis pour être un unix ! Si, si, c'est vrai, certains le pensent ! Enfin certains pensent aussi qu'un ordinateur unix doit avoir un clavier et un écran ! Sans déc' !
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Le 20/07/03 15:18, dans <rfcispxqqtb.fsf@moulon.inra.fr>, « ts »
<decoux@moulon.inra.fr> a écrit :
"É" == Éric Lévénez <eric@levenez.com> writes:
On prévient quand on change les groupes
É> Quelle belle connerie que cette définition d'unix ! Mac OS X gère les
É> bibliothèques dynamiques d'une autre façon que les unix utilisant ELF. Et
É> alors ?
Essayez de les utiliser
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement
lier des fonctions alors que la façon ELF bride à fond ce type de
comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais?
As-tu regarder ce que permettait xcode en matière de comportement dynamique.
Dyld permet aussi de gérer finement les versions, ce que ne permet pas les
implémentations "traditionnelles" ELF, c'est mal ?
C'est quand même stupéfiant que certains considèrent que ELF est la base
d'unix ! Je pense que certains considèrent même que X Window System est
requis pour être un unix ! Si, si, c'est vrai, certains le pensent ! Enfin
certains pensent aussi qu'un ordinateur unix doit avoir un clavier et un
écran ! Sans déc' !
--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.
É> Quelle belle connerie que cette définition d'unix ! Mac OS X gère les É> bibliothèques dynamiques d'une autre façon que les unix utilisant ELF. Et É> alors ?
Essayez de les utiliser
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement lier des fonctions alors que la façon ELF bride à fond ce type de comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais? As-tu regarder ce que permettait xcode en matière de comportement dynamique. Dyld permet aussi de gérer finement les versions, ce que ne permet pas les implémentations "traditionnelles" ELF, c'est mal ?
C'est quand même stupéfiant que certains considèrent que ELF est la base d'unix ! Je pense que certains considèrent même que X Window System est requis pour être un unix ! Si, si, c'est vrai, certains le pensent ! Enfin certains pensent aussi qu'un ordinateur unix doit avoir un clavier et un écran ! Sans déc' !
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
manu
Éric Lévénez wrote:
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement lier des fonctions alors que la façon ELF bride à fond ce type de comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais? As-tu regarder ce que permettait xcode en matière de comportement dynamique. Dyld permet aussi de gérer finement les versions, ce que ne permet pas les implémentations "traditionnelles" ELF, c'est mal ?
ELF a d'autre limitations malheureuses. Le format Mach-O permet de faire des binaires FAT, c'est bien pratique. Je crois (pas sur) que Mach-O permet de charger un module dynamique dans un binaire statique, ce qui est impossible en ELF.
Bon, par contre, y'a des trucs nuls dans les librairies dynamiques de MacOS X. Cette manie de charger des librairies recursivement, par exemple, c'est pas super rapide.
-- Emmanuel Dreyfus
Éric Lévénez <eric@levenez.com> wrote:
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement
lier des fonctions alors que la façon ELF bride à fond ce type de
comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais?
As-tu regarder ce que permettait xcode en matière de comportement dynamique.
Dyld permet aussi de gérer finement les versions, ce que ne permet pas les
implémentations "traditionnelles" ELF, c'est mal ?
ELF a d'autre limitations malheureuses. Le format Mach-O permet de faire
des binaires FAT, c'est bien pratique. Je crois (pas sur) que Mach-O
permet de charger un module dynamique dans un binaire statique, ce qui
est impossible en ELF.
Bon, par contre, y'a des trucs nuls dans les librairies dynamiques de
MacOS X. Cette manie de charger des librairies recursivement, par
exemple, c'est pas super rapide.
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement lier des fonctions alors que la façon ELF bride à fond ce type de comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais? As-tu regarder ce que permettait xcode en matière de comportement dynamique. Dyld permet aussi de gérer finement les versions, ce que ne permet pas les implémentations "traditionnelles" ELF, c'est mal ?
ELF a d'autre limitations malheureuses. Le format Mach-O permet de faire des binaires FAT, c'est bien pratique. Je crois (pas sur) que Mach-O permet de charger un module dynamique dans un binaire statique, ce qui est impossible en ELF.
Bon, par contre, y'a des trucs nuls dans les librairies dynamiques de MacOS X. Cette manie de charger des librairies recursivement, par exemple, c'est pas super rapide.
-- Emmanuel Dreyfus
manu
pasAlanpasCox wrote:
Est ce que pour vous une machine avec MacOS X peut être considéré comme une station unix au même titre qu'une sb, ou qu'un C3xxx?
Qu'entends tu exactement par sb ou C3xxx?
-- Emmanuel Dreyfus
pasAlanpasCox <bill@bill.com> wrote:
Est ce que pour vous une machine avec MacOS X peut être considéré comme
une station unix au même titre qu'une sb, ou qu'un C3xxx?
Est ce que pour vous une machine avec MacOS X peut être considéré comme une station unix au même titre qu'une sb, ou qu'un C3xxx?
Qu'entends tu exactement par sb ou C3xxx?
-- Emmanuel Dreyfus
Éric Lévénez
Le 20/07/03 20:54, dans <1fyext2.8qypzc7x63n2N%, « Emmanuel Dreyfus » a écrit :
Éric Lévénez wrote:
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement lier des fonctions alors que la façon ELF bride à fond ce type de comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais? As-tu regarder ce que permettait xcode en matière de comportement dynamique. Dyld permet aussi de gérer finement les versions, ce que ne permet pas les implémentations "traditionnelles" ELF, c'est mal ?
ELF a d'autre limitations malheureuses. Le format Mach-O permet de faire des binaires FAT, c'est bien pratique.
C'est SUPER pratique, cela évite d'avoir différents répertoires pour les binaires dès qu'on a un serveur de fichiers supportant un même OS avec différents CPU ou versions de CPU. Il y avait ces répertoires sur SunOS du temps où Sun faisait des i386... Apple pourra se servir du fat-binary de Mach-O pour gérer son PPC 970 en mode 64 bits. Ils l'avaient utilisé du temps de Rhapsody sur les outils de développement x86 et ppc.
Je crois (pas sur) que Mach-O permet de charger un module dynamique dans un binaire statique, ce qui est impossible en ELF.
Bon, par contre, y'a des trucs nuls dans les librairies dynamiques de MacOS X. Cette manie de charger des librairies recursivement, par exemple, c'est pas super rapide.
Même sans parler de récursivité, les liens dynamiques ne sont pas rapides du tout, même s'ils permettent beaucoup de choses. Du temps de NeXTSTEP les bibliothèques (fat-binaries elles aussi) étaient plus petites que sur Mac OS X et se chargeaient 10 ou 100 fois plus vite sur des CPU 100 fois plus lents. Le pre-binding a fait évoluer les choses dans le bon sens.
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Le 20/07/03 20:54, dans <1fyext2.8qypzc7x63n2N%manu@netbsd.org>, « Emmanuel
Dreyfus » <manu@netbsd.org> a écrit :
Éric Lévénez <eric@levenez.com> wrote:
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement
lier des fonctions alors que la façon ELF bride à fond ce type de
comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais?
As-tu regarder ce que permettait xcode en matière de comportement dynamique.
Dyld permet aussi de gérer finement les versions, ce que ne permet pas les
implémentations "traditionnelles" ELF, c'est mal ?
ELF a d'autre limitations malheureuses. Le format Mach-O permet de faire
des binaires FAT, c'est bien pratique.
C'est SUPER pratique, cela évite d'avoir différents répertoires pour les
binaires dès qu'on a un serveur de fichiers supportant un même OS avec
différents CPU ou versions de CPU. Il y avait ces répertoires sur SunOS du
temps où Sun faisait des i386... Apple pourra se servir du fat-binary de
Mach-O pour gérer son PPC 970 en mode 64 bits. Ils l'avaient utilisé du
temps de Rhapsody sur les outils de développement x86 et ppc.
Je crois (pas sur) que Mach-O
permet de charger un module dynamique dans un binaire statique, ce qui
est impossible en ELF.
Bon, par contre, y'a des trucs nuls dans les librairies dynamiques de
MacOS X. Cette manie de charger des librairies recursivement, par
exemple, c'est pas super rapide.
Même sans parler de récursivité, les liens dynamiques ne sont pas rapides du
tout, même s'ils permettent beaucoup de choses. Du temps de NeXTSTEP les
bibliothèques (fat-binaries elles aussi) étaient plus petites que sur Mac OS
X et se chargeaient 10 ou 100 fois plus vite sur des CPU 100 fois plus
lents. Le pre-binding a fait évoluer les choses dans le bon sens.
--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.
Le 20/07/03 20:54, dans <1fyext2.8qypzc7x63n2N%, « Emmanuel Dreyfus » a écrit :
Éric Lévénez wrote:
Oui, et c'est quoi le/ton problème ? Tu trouves que l'on peut dynamiquement lier des fonctions alors que la façon ELF bride à fond ce type de comportement, mais que ce n'est pas ce que tu utilises, alors c'est mauvais? As-tu regarder ce que permettait xcode en matière de comportement dynamique. Dyld permet aussi de gérer finement les versions, ce que ne permet pas les implémentations "traditionnelles" ELF, c'est mal ?
ELF a d'autre limitations malheureuses. Le format Mach-O permet de faire des binaires FAT, c'est bien pratique.
C'est SUPER pratique, cela évite d'avoir différents répertoires pour les binaires dès qu'on a un serveur de fichiers supportant un même OS avec différents CPU ou versions de CPU. Il y avait ces répertoires sur SunOS du temps où Sun faisait des i386... Apple pourra se servir du fat-binary de Mach-O pour gérer son PPC 970 en mode 64 bits. Ils l'avaient utilisé du temps de Rhapsody sur les outils de développement x86 et ppc.
Je crois (pas sur) que Mach-O permet de charger un module dynamique dans un binaire statique, ce qui est impossible en ELF.
Bon, par contre, y'a des trucs nuls dans les librairies dynamiques de MacOS X. Cette manie de charger des librairies recursivement, par exemple, c'est pas super rapide.
Même sans parler de récursivité, les liens dynamiques ne sont pas rapides du tout, même s'ils permettent beaucoup de choses. Du temps de NeXTSTEP les bibliothèques (fat-binaries elles aussi) étaient plus petites que sur Mac OS X et se chargeaient 10 ou 100 fois plus vite sur des CPU 100 fois plus lents. Le pre-binding a fait évoluer les choses dans le bon sens.
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
manu
Éric Lévénez wrote:
Même sans parler de récursivité, les liens dynamiques ne sont pas rapides du tout, même s'ils permettent beaucoup de choses. Du temps de NeXTSTEP les bibliothèques (fat-binaries elles aussi) étaient plus petites que sur Mac OS X et se chargeaient 10 ou 100 fois plus vite sur des CPU 100 fois plus lents. Le pre-binding a fait évoluer les choses dans le bon sens.
Tu parles... si tu traces un programme, tu t'apercois que le linker dynamique va remapper des librairies déjà mappées lors de ses passes recursives.
Y'a aussi un truc pas net avec la libSystem qui est mappée par le kernel et que le linker dynamique commence par remapper. Bref, ils se sont laissé de la place pour l'optimisation.
-- Emmanuel Dreyfus
Éric Lévénez <eric@levenez.com> wrote:
Même sans parler de récursivité, les liens dynamiques ne sont pas rapides du
tout, même s'ils permettent beaucoup de choses. Du temps de NeXTSTEP les
bibliothèques (fat-binaries elles aussi) étaient plus petites que sur Mac OS
X et se chargeaient 10 ou 100 fois plus vite sur des CPU 100 fois plus
lents. Le pre-binding a fait évoluer les choses dans le bon sens.
Tu parles... si tu traces un programme, tu t'apercois que le linker
dynamique va remapper des librairies déjà mappées lors de ses passes
recursives.
Y'a aussi un truc pas net avec la libSystem qui est mappée par le kernel
et que le linker dynamique commence par remapper. Bref, ils se sont
laissé de la place pour l'optimisation.
Même sans parler de récursivité, les liens dynamiques ne sont pas rapides du tout, même s'ils permettent beaucoup de choses. Du temps de NeXTSTEP les bibliothèques (fat-binaries elles aussi) étaient plus petites que sur Mac OS X et se chargeaient 10 ou 100 fois plus vite sur des CPU 100 fois plus lents. Le pre-binding a fait évoluer les choses dans le bon sens.
Tu parles... si tu traces un programme, tu t'apercois que le linker dynamique va remapper des librairies déjà mappées lors de ses passes recursives.
Y'a aussi un truc pas net avec la libSystem qui est mappée par le kernel et que le linker dynamique commence par remapper. Bref, ils se sont laissé de la place pour l'optimisation.
-- Emmanuel Dreyfus
Ollivier Robert
Dans l'article , ts disait :
Non, une chose qui ne sait pas travailler avec les librairies dynamiques ne peut pas être considéré comme un un*x
C'est là une conclusion bien rapide que l'article en question ne permet pas d'avoir tel que je le lis. Un certain nombre de logiciels génère et utilise des bibliothèques partagées sur MacOS X, y compris Ruby :-) -- Ollivier ROBERT -=- Eurocontrol EEC/AMI -=- FreeBSD : <URL:http://www.FreeBSD.org/> The Power to Serve!
Dans l'article <rfcn0f9qydn.fsf@moulon.inra.fr>,
ts <decoux@moulon.inra.fr> disait :
Non, une chose qui ne sait pas travailler avec les librairies dynamiques ne
peut pas être considéré comme un un*x
C'est là une conclusion bien rapide que l'article en question ne permet pas
d'avoir tel que je le lis. Un certain nombre de logiciels génère et utilise
des bibliothèques partagées sur MacOS X, y compris Ruby :-)
--
Ollivier ROBERT -=- Eurocontrol EEC/AMI -=- roberto@eurocontrol.fr
FreeBSD : <URL:http://www.FreeBSD.org/> The Power to Serve!
C'est là une conclusion bien rapide que l'article en question ne permet pas d'avoir tel que je le lis. Un certain nombre de logiciels génère et utilise des bibliothèques partagées sur MacOS X, y compris Ruby :-) -- Ollivier ROBERT -=- Eurocontrol EEC/AMI -=- FreeBSD : <URL:http://www.FreeBSD.org/> The Power to Serve!
ts
"O" == Ollivier Robert writes:
O> des bibliothèques partagées sur MacOS X, y compris Ruby :-)
Lisez le README de bdbxml
--
Guy Decoux
"O" == Ollivier Robert <roberto@REMOVETHIS.eu.org> writes:
O> des bibliothèques partagées sur MacOS X, y compris Ruby :-)
