Le vrai gros avantage de la eglibc par rapport à glibc la dernière fois que j'ai regardé, c'était surtout qu'il était beaucoup plus facile de compiler une cross-toolchain. Les inter-dépendances entre la gcc et la glibc sont un vrai cauchemar pour mettre en œuvre une cross-toolchain (le plus facile étant les GNU binutils).
En effet, la compilation native n'est qu'un cas particulier de la compilation croisée (passons les trolls sur la compilation canadienne), pourtant énormément de paquets de sources logiciels sont codés en dur, ou de vrais cauchemars, pour la compilation croisée. C'est pour cela qu'il est bon de se forcer un peu au début d'un projet de bien utiliser les GNU autotools qui donne accès à un framework de compilation croisée pour gratuit.
U.D. est difficile, mais les derniers choix qu'il a fait (nouveau cycle de release, passage à git) et ses compétences (voir son papier sur le fait que la RAM est lente et que pour de la vraie performance il fallait gérer la mémoire cache) compensent largement le fait qu'il hurle à la mort à chaque fois qu'un patch casse la compatibilité avec le HURD (véridique).
Accessoirement, il fait parti des gens qui font POSIX...
trollS:
- automake en C... mon rêve.
- eglibc passe à git, ça c'est une bonne idée
- Je rêve d'une GNU/Linux gentoo où portage est en C et surtout pensé dés le départ pour de la compilation/déploiement croisé car pour le moment, cette fonctionnalité est monkey patché progressivement dans portage et... bof bof.
[^] # Re: Glibc 2.10
Posté par blubliblo . En réponse au journal Debian migre de la GNU libc à EGLIBC. Évalué à 6.
En effet, la compilation native n'est qu'un cas particulier de la compilation croisée (passons les trolls sur la compilation canadienne), pourtant énormément de paquets de sources logiciels sont codés en dur, ou de vrais cauchemars, pour la compilation croisée. C'est pour cela qu'il est bon de se forcer un peu au début d'un projet de bien utiliser les GNU autotools qui donne accès à un framework de compilation croisée pour gratuit.
U.D. est difficile, mais les derniers choix qu'il a fait (nouveau cycle de release, passage à git) et ses compétences (voir son papier sur le fait que la RAM est lente et que pour de la vraie performance il fallait gérer la mémoire cache) compensent largement le fait qu'il hurle à la mort à chaque fois qu'un patch casse la compatibilité avec le HURD (véridique).
Accessoirement, il fait parti des gens qui font POSIX...
trollS:
- automake en C... mon rêve.
- eglibc passe à git, ça c'est une bonne idée
- Je rêve d'une GNU/Linux gentoo où portage est en C et surtout pensé dés le départ pour de la compilation/déploiement croisé car pour le moment, cette fonctionnalité est monkey patché progressivement dans portage et... bof bof.