J'ai écris un programme C qui fonctionne sous Linux et *BSD.
Ce programme contient des sections :
#ifdef LINUX
...
#endif // LINUX
#ifdef NETBSD
...
#endif
#ifdef FREEBSD
...
#endif
etc.
car j'utilise des appels systèmes qui ne fonctionnent que selon l'OS.
Pour compiler, j'utilise par exemple la commande suivante :
gcc -o upclient main.c -Wall -DFREEBSD
Mon problème actuel est que je dois compiler sous chaque OS... donc
j'utilise qemu pour les émuler le temps de compiler.
Second problème, si je compile sous FreeBSD 6.x, le binaire ne
fonctionnera pas sous la 4.x voire la 5. Idem pour NetBSD et OpenBSD.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Ma question, y a-t-il moyen de compiler une bonne fois pour toute le
source (sous FreeBSd par ex) et qu'il fonctionne sous n'importe quel
Unix/Linux par la suite ?
La plus mauvaise réponse à cette fausse question que l'industrie a it trouvé jusqu'alors est Java et son bytecode.
J'ai pas compris.
La différence entre un langage compilé et un langage plus-ou-moins interprété est que la compatibilité entre architectures est assuré e (au mieux) au niveau code source dans les langages compilés.
Delf wrote:
La plus mauvaise réponse à cette fausse question que l'industrie a it
trouvé jusqu'alors est Java et son bytecode.
J'ai pas compris.
La différence entre un langage compilé et un langage plus-ou-moins
interprété est que la compatibilité entre architectures est assuré e (au
mieux) au niveau code source dans les langages compilés.
La plus mauvaise réponse à cette fausse question que l'industrie a it trouvé jusqu'alors est Java et son bytecode.
J'ai pas compris.
La différence entre un langage compilé et un langage plus-ou-moins interprété est que la compatibilité entre architectures est assuré e (au mieux) au niveau code source dans les langages compilés.
david
Emmanuel Dreyfus wrote:
Soit dit en passant, gcc définit des symboles pour l'OS: __NetBSD__ sous NetBSD, __FreeBSD__ sous FreeBSD, etc...
Pour avoir la liste: cpp -dM /dev/null
ça fait des années que je la cherche celle là !
Merci :-)
Emmanuel Dreyfus <manu@netbsd.org> wrote:
Soit dit en passant, gcc définit des symboles pour l'OS:
__NetBSD__ sous NetBSD, __FreeBSD__ sous FreeBSD, etc...
Soit dit en passant, gcc définit des symboles pour l'OS: __NetBSD__ sous NetBSD, __FreeBSD__ sous FreeBSD, etc...
Pour avoir la liste: cpp -dM /dev/null
ça fait des années que je la cherche celle là !
Merci :-)
Delf
La différence entre un langage compilé et un langage plus-ou-moins interprété est que la compatibilité entre architectures est assurée (au mieux) au niveau code source dans les langages compilés.
Je ne vois pas en quoi cela est mal :) On ne peut pas tout avoir.
-- Delf
La différence entre un langage compilé et un langage plus-ou-moins
interprété est que la compatibilité entre architectures est assurée (au
mieux) au niveau code source dans les langages compilés.
Je ne vois pas en quoi cela est mal :) On ne peut pas tout avoir.
La différence entre un langage compilé et un langage plus-ou-moins interprété est que la compatibilité entre architectures est assurée (au mieux) au niveau code source dans les langages compilés.
Je ne vois pas en quoi cela est mal :) On ne peut pas tout avoir.
Mon problème actuel est que je dois compiler sous chaque OS... donc j'utilise qemu pour les émuler le temps de compiler.
Second problème, si je compile sous FreeBSD 6.x, le binaire ne fonctionnera pas sous la 4.x voire la 5. Idem pour NetBSD et OpenBSD.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Ma question, y a-t-il moyen de compiler une bonne fois pour toute le source (sous FreeBSd par ex) et qu'il fonctionne sous n'importe quel Unix/Linux par la suite ?
La piste que vous cherchez à explorer est mauvaise parce que vous avez oublié une partie du problème en cours de route : il ne suffit pas de compiler (produire un fichier binaire exécutable pour une ou plusieurs architectures données)... Il faut aussi tester ! Or pour tester, il faut disposer d'un environnement avec l'OS et l'architecture matériel (un environnement réel ou simulé... même si le réel est plus sûr pour la fiabilité des tests). Or donc, si vous disposez de ces environnements, la plupart peuvent aussi faire la compilation elle-même. Il n'y a guère que les environnements embarqués (avec peu de ressources) où le passage par la cross-compilation semble justifié.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Mon problème actuel est que je dois compiler sous chaque OS... donc
j'utilise qemu pour les émuler le temps de compiler.
Second problème, si je compile sous FreeBSD 6.x, le binaire ne
fonctionnera pas sous la 4.x voire la 5. Idem pour NetBSD et OpenBSD.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Ma question, y a-t-il moyen de compiler une bonne fois pour toute le
source (sous FreeBSd par ex) et qu'il fonctionne sous n'importe quel
Unix/Linux par la suite ?
La piste que vous cherchez à explorer est mauvaise parce que vous avez
oublié une partie du problème en cours de route : il ne suffit pas de
compiler (produire un fichier binaire exécutable pour une ou plusieurs
architectures données)... Il faut aussi tester ! Or pour tester, il
faut disposer d'un environnement avec l'OS et l'architecture matériel
(un environnement réel ou simulé... même si le réel est plus sûr pour
la fiabilité des tests). Or donc, si vous disposez de ces
environnements, la plupart peuvent aussi faire la compilation
elle-même. Il n'y a guère que les environnements embarqués (avec peu
de ressources) où le passage par la cross-compilation semble justifié.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Mon problème actuel est que je dois compiler sous chaque OS... donc j'utilise qemu pour les émuler le temps de compiler.
Second problème, si je compile sous FreeBSD 6.x, le binaire ne fonctionnera pas sous la 4.x voire la 5. Idem pour NetBSD et OpenBSD.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Ma question, y a-t-il moyen de compiler une bonne fois pour toute le source (sous FreeBSd par ex) et qu'il fonctionne sous n'importe quel Unix/Linux par la suite ?
La piste que vous cherchez à explorer est mauvaise parce que vous avez oublié une partie du problème en cours de route : il ne suffit pas de compiler (produire un fichier binaire exécutable pour une ou plusieurs architectures données)... Il faut aussi tester ! Or pour tester, il faut disposer d'un environnement avec l'OS et l'architecture matériel (un environnement réel ou simulé... même si le réel est plus sûr pour la fiabilité des tests). Or donc, si vous disposez de ces environnements, la plupart peuvent aussi faire la compilation elle-même. Il n'y a guère que les environnements embarqués (avec peu de ressources) où le passage par la cross-compilation semble justifié.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Mon problème actuel est que je dois compiler sous chaque OS... donc j'utilise qemu pour les émuler le temps de compiler.
Second problème, si je compile sous FreeBSD 6.x, le binaire ne fonctionnera pas sous la 4.x voire la 5. Idem pour NetBSD et OpenBSD.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Ma question, y a-t-il moyen de compiler une bonne fois pour toute le source (sous FreeBSd par ex) et qu'il fonctionne sous n'importe quel Unix/Linux par la suite ?
La piste que vous cherchez à explorer est mauvaise parce que vous avez oublié une partie du problème en cours de route : il ne suffit pas de compiler (produire un fichier binaire exécutable pour une ou plusieurs architectures données)... Il faut aussi tester ! Or pour tester, il faut disposer d'un environnement avec l'OS et l'architecture matériel (un environnement réel ou simulé... même si le réel est plus sûr pour la fiabilité des tests). Or donc, si vous disposez de ces environnements, la plupart peuvent aussi faire la compilation elle-même. Il n'y a guère que les environnements embarqués (avec peu de ressources) où le passage par la cross-compilation semble justifié.
Vous avez tout à fait raison en soulignant la nécessité de tester une distribution sur les systèmes sur lesquels elle est censée s'installer et marcher. Mais les problèmes de la fabrication de distributions et de leurs tests peut être d'une certaine manière disjoints.
Il est plus fiable d'avoir tous les environnement matériels et logiciels pour mener les tests mais une même personne (physique ou morale) me peut pas toujours avoir 5 ou 6 arch. matérielles voire même seulement logicielles et même si elle avait toutes les arch. logicielle, le mieux pour être sûr est de rebooter... chose qui devrait amha être réservé au choses qui touchent le kernel et qui de ce fait échappent au problème.
Pour résumer, si il y a une nécessité de tests d'une distribution sur plusieurs environnements, ces tests peuvent être distribués sur des machines, des réseaux etc. différents, par des personnes qui ne sont pas celle qui ont fabriqué la distribution, en plus cela permet de tester dans des environnements qui n'ont pas été façonnés suivant l'idiosyncrasie du faiseur de distributions. C'est en cela qu'il peut être bon que ces problèmes soient disjoints et distribués.
Mon problème actuel est que je dois compiler sous chaque OS... donc
j'utilise qemu pour les émuler le temps de compiler.
Second problème, si je compile sous FreeBSD 6.x, le binaire ne
fonctionnera pas sous la 4.x voire la 5. Idem pour NetBSD et OpenBSD.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Ma question, y a-t-il moyen de compiler une bonne fois pour toute le
source (sous FreeBSd par ex) et qu'il fonctionne sous n'importe quel
Unix/Linux par la suite ?
La piste que vous cherchez à explorer est mauvaise parce que vous avez
oublié une partie du problème en cours de route : il ne suffit pas de
compiler (produire un fichier binaire exécutable pour une ou plusieurs
architectures données)... Il faut aussi tester ! Or pour tester, il
faut disposer d'un environnement avec l'OS et l'architecture matériel
(un environnement réel ou simulé... même si le réel est plus sûr pour
la fiabilité des tests). Or donc, si vous disposez de ces
environnements, la plupart peuvent aussi faire la compilation
elle-même. Il n'y a guère que les environnements embarqués (avec peu
de ressources) où le passage par la cross-compilation semble justifié.
Vous avez tout à fait raison en soulignant la nécessité de tester une
distribution sur les systèmes sur lesquels elle est censée s'installer
et marcher. Mais les problèmes de la fabrication de distributions et de
leurs tests peut être d'une certaine manière disjoints.
Il est plus fiable d'avoir tous les environnement matériels et logiciels
pour mener les tests mais une même personne (physique ou morale) me
peut pas toujours avoir 5 ou 6 arch. matérielles voire même seulement
logicielles et même si elle avait toutes les arch. logicielle, le mieux
pour être sûr est de rebooter... chose qui devrait amha être réservé au
choses qui touchent le kernel et qui de ce fait échappent au problème.
Pour résumer, si il y a une nécessité de tests d'une distribution sur
plusieurs environnements, ces tests peuvent être distribués sur des
machines, des réseaux etc. différents, par des personnes qui ne sont
pas celle qui ont fabriqué la distribution, en plus cela permet de
tester dans des environnements qui n'ont pas été façonnés suivant
l'idiosyncrasie du faiseur de distributions.
C'est en cela qu'il peut être bon que ces problèmes soient disjoints et
distribués.
Mon problème actuel est que je dois compiler sous chaque OS... donc j'utilise qemu pour les émuler le temps de compiler.
Second problème, si je compile sous FreeBSD 6.x, le binaire ne fonctionnera pas sous la 4.x voire la 5. Idem pour NetBSD et OpenBSD.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Ma question, y a-t-il moyen de compiler une bonne fois pour toute le source (sous FreeBSd par ex) et qu'il fonctionne sous n'importe quel Unix/Linux par la suite ?
La piste que vous cherchez à explorer est mauvaise parce que vous avez oublié une partie du problème en cours de route : il ne suffit pas de compiler (produire un fichier binaire exécutable pour une ou plusieurs architectures données)... Il faut aussi tester ! Or pour tester, il faut disposer d'un environnement avec l'OS et l'architecture matériel (un environnement réel ou simulé... même si le réel est plus sûr pour la fiabilité des tests). Or donc, si vous disposez de ces environnements, la plupart peuvent aussi faire la compilation elle-même. Il n'y a guère que les environnements embarqués (avec peu de ressources) où le passage par la cross-compilation semble justifié.
Vous avez tout à fait raison en soulignant la nécessité de tester une distribution sur les systèmes sur lesquels elle est censée s'installer et marcher. Mais les problèmes de la fabrication de distributions et de leurs tests peut être d'une certaine manière disjoints.
Il est plus fiable d'avoir tous les environnement matériels et logiciels pour mener les tests mais une même personne (physique ou morale) me peut pas toujours avoir 5 ou 6 arch. matérielles voire même seulement logicielles et même si elle avait toutes les arch. logicielle, le mieux pour être sûr est de rebooter... chose qui devrait amha être réservé au choses qui touchent le kernel et qui de ce fait échappent au problème.
Pour résumer, si il y a une nécessité de tests d'une distribution sur plusieurs environnements, ces tests peuvent être distribués sur des machines, des réseaux etc. différents, par des personnes qui ne sont pas celle qui ont fabriqué la distribution, en plus cela permet de tester dans des environnements qui n'ont pas été façonnés suivant l'idiosyncrasie du faiseur de distributions. C'est en cela qu'il peut être bon que ces problèmes soient disjoints et distribués.
-- Patrick http://patrick.davalan.free.fr/
Jérémy JUST
On Wed, 05 Apr 2006 09:56:47 +0200 Delf wrote:
[Java] La différence entre un langage compilé et un langage plus-ou-moins
interprété est que la compatibilité entre architectures est assurée (au Je ne vois pas en quoi cela est mal :) On ne peut pas tout avoir.
Si on réfléchit un peu plus loin que ce qui est dit dans les publicités, ce n'est absolument pas une solution au problème, puisqu'il faut de toutes façons une machine virtuelle par OS/architecture.
Bilan des courses: - on a le problème de portabilité binaire pour la machine virtuelle, - le bytecode est encore tellement proche du code qu'il peut souvent être décompilé.
Résumé: au lieu d'avoir soit un problème de portabilité du binaire, soit un problème de lisibilité excessive du code, on a cumulé les deux! Trop fort, Java!
-- Jérémy JUST
On Wed, 05 Apr 2006 09:56:47 +0200
Delf <none@none.org> wrote:
[Java]
La différence entre un langage compilé et un langage plus-ou-moins
interprété est que la compatibilité entre architectures est assurée (au
Je ne vois pas en quoi cela est mal :) On ne peut pas tout avoir.
Si on réfléchit un peu plus loin que ce qui est dit dans les publicités,
ce n'est absolument pas une solution au problème, puisqu'il faut de toutes
façons une machine virtuelle par OS/architecture.
Bilan des courses:
- on a le problème de portabilité binaire pour la machine virtuelle,
- le bytecode est encore tellement proche du code qu'il peut souvent être
décompilé.
Résumé: au lieu d'avoir soit un problème de portabilité du binaire, soit
un problème de lisibilité excessive du code, on a cumulé les deux!
Trop fort, Java!
[Java] La différence entre un langage compilé et un langage plus-ou-moins
interprété est que la compatibilité entre architectures est assurée (au Je ne vois pas en quoi cela est mal :) On ne peut pas tout avoir.
Si on réfléchit un peu plus loin que ce qui est dit dans les publicités, ce n'est absolument pas une solution au problème, puisqu'il faut de toutes façons une machine virtuelle par OS/architecture.
Bilan des courses: - on a le problème de portabilité binaire pour la machine virtuelle, - le bytecode est encore tellement proche du code qu'il peut souvent être décompilé.
Résumé: au lieu d'avoir soit un problème de portabilité du binaire, soit un problème de lisibilité excessive du code, on a cumulé les deux! Trop fort, Java!
-- Jérémy JUST
manu
Delf wrote:
Résumé: au lieu d'avoir soit un problème de portabilité du binaire, soit un problème de lisibilité excessive du code, on a cumulé les deux! Trop fort, Java!
Sûrement :) Mais cela apporte aussi de bonnes choses non ? =)
En ce qui me concerne je ne les pas encore trouvées.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Delf <none@none.org> wrote:
Résumé: au lieu d'avoir soit un problème de portabilité du binaire, soit
un problème de lisibilité excessive du code, on a cumulé les deux!
Trop fort, Java!
Sûrement :)
Mais cela apporte aussi de bonnes choses non ? =)
En ce qui me concerne je ne les pas encore trouvées.
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Résumé: au lieu d'avoir soit un problème de portabilité du binaire, soit un problème de lisibilité excessive du code, on a cumulé les deux! Trop fort, Java!
Sûrement :) Mais cela apporte aussi de bonnes choses non ? =)
En ce qui me concerne je ne les pas encore trouvées.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Delf
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
Y at-il un support PDF ?
-- Delf
Le cahier de l'admin BSD 2eme ed. est dans toutes les
bonnes librairies
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies Y at-il un support PDF ?
Evidemment y'a une version PDF, mais elle n'est pas commercialisée. Sur un disque dur qui est dans un coffre jeté au fond de l'ocean et dont la clé a été mangée par un requin.
Où est le diff avec la première édition ?
Avec le PDF.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Arnaud Launay <asl@launay.org> wrote:
Le cahier de l'admin BSD 2eme ed. est dans toutes les
bonnes librairies
Y at-il un support PDF ?
Evidemment y'a une version PDF, mais elle n'est pas commercialisée.
Sur un disque dur qui est dans un coffre jeté au fond de l'ocean et dont
la clé a été mangée par un requin.
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies Y at-il un support PDF ?
Evidemment y'a une version PDF, mais elle n'est pas commercialisée. Sur un disque dur qui est dans un coffre jeté au fond de l'ocean et dont la clé a été mangée par un requin.
