Bonjour.

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 ?

Merci d'avance.

--
Delf

Delf wrote in message <44313985$0$9636$636a55ce@news.free.fr>:
> 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 ?

Non. Les OS que tu as cités peuvent tourner sur différentes architectures,
c'est une fin de non recevoir à l'espoir d'avoir un binaire universel.

La solution normale à ce problème, c'est de distribuer le code source.

Delf <none@none.org> writes:

> 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 ?

Non. Le plus proche serait de compiler vers autre chose que de
l'assembleur, une machine virtuelle. Mais alors tu te retrouves avec
le probleme de t'assurer que la machine virtuelle est presente sur tes
cibles d'une part, et avec la bonne version d'autre part :-) (Note que
la machine virtuelle peut etre un sous-ensemble de perl ou de sh).

Plutot que de compiler sous un emulateur, tu peux aussi t'installer
des compilateurs croises. C'est vraissemblablement plus difficile a
mettre en place la premiere fois, mais les perfs de compilation
devraient etre meilleures.

A+

--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Delf wrote:

>
> 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 ?

J'ai peur que cela ne soit pas si simple...

Sauf erreur, c'est au moment de l'installation de gcc que celui-ci doit
être batit pour une plateforme cible, du moins du point de vue
matériel,
voir http://www.nongnu.org/thug/cross.html

Si c'est un problème d'OS seulement, je crois qu'il y a des formats de
sortie difféents possibles. Mais je ne connais pas, peut-être qu'en
gogolisant...
De toute manière, dans le meilleur des cas, il faudra 1 compile par
objet exécutable, avec écentuellement un gcc différent par plateforme
cible.

Je ne suis pas sûr d'avoir é...

--
http://harpo.free.fr/

Jean-Marc Bourguet a écrit :

> Non. Le plus proche serait de compiler vers autre chose que de
> l'assembleur, une machine virtuelle. Mais alors tu te retrouves avec
> le probleme de t'assurer que la machine virtuelle est presente sur tes
> cibles d'une part, et avec la bonne version d'autre part :-) (Note que
> la machine virtuelle peut etre un sous-ensemble de perl ou de sh).

Inconcevable :\

> Plutot que de compiler sous un emulateur, tu peux aussi t'installer
> des compilateurs croises. C'est vraissemblablement plus difficile a
> mettre en place la premiere fois, mais les perfs de compilation
> devraient etre meilleures.

La compilation ne prend que quelques secondes, le problème, c'est tous
ces OS :\

--
Delf

Nicolas George a écrit :

> Non. Les OS que tu as cités peuvent tourner sur différentes architectures,
> c'est une fin de non recevoir à l'espoir d'avoir un binaire universel.

:\

> La solution normale à ce problème, c'est de distribuer le code source.

Pas possible hélas...

--
Delf

Delf <none@none.org> writes:

> Jean-Marc Bourguet a écrit :
>
> > Non. Le plus proche serait de compiler vers autre chose que de
> > l'assembleur, une machine virtuelle. Mais alors tu te retrouves avec
> > le probleme de t'assurer que la machine virtuelle est presente sur tes
> > cibles d'une part, et avec la bonne version d'autre part :-) (Note que
> > la machine virtuelle peut etre un sous-ensemble de perl ou de sh).
>
> Inconcevable :\
>
> > Plutot que de compiler sous un emulateur, tu peux aussi t'installer
> > des compilateurs croises. C'est vraissemblablement plus difficile a
> > mettre en place la premiere fois, mais les perfs de compilation
> > devraient etre meilleures.
>
> La compilation ne prend que quelques secondes, le problème, c'est tous ces
> OS :\

Donne plus d'info sur ce que tu veux faire parce que pour le moment,
on ne connait pas le probleme, uniquement la solution qui ne te
convient pas.

Une autre idee dans le vide: faire une couche qui abstrait les
dependances sur l'OS. Ca peut limiter le nombre d'objet a lier a
nombre de couple ABI/architecture. C'est impossible a passer en
dessous sauf a trouver des sous-ensembles commun entre plusieurs ABI.

Une autre idee, utiliser un module de compilation JIT (GNU en avait un
mais si fournir les sources n'est pas une solution...).

A+

--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Harpo <trashcan@hotmail.com> wrote:
> Delf wrote:
>> 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 ?
>
> Sauf erreur, c'est au moment de l'installation de gcc que celui-ci doit
> être batit pour une plateforme cible, du moins du point de vue
> matériel,
> voir http://www.nongnu.org/thug/cross.html

Oui.

Je produit régulièrement des binaires windows sous linux comme cela.
Et également des binaires ARM.

Il faut au pire compiler un gcc par architecture. C'est l'option --target du
configure de gcc il me semble. Apres avoir bâti la chaine de compilation, il
faut bâtir la glibc pour cette cible également pour pouvoir produire un
executable.

Les mot clés google "cross tool chain" doivent pouvoir aider.

david

Delf <none@none.org> wrote:

> gcc -o upclient main.c -Wall -DFREEBSD

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

Ca evite d'avoir à mettre un -DFREEBSD...

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique.../livre-bsd.php
manu@netbsd.org

Delf wrote:
> Nicolas George a écrit :

>> La solution normale à ce problème, c'est de distribuer le code source.
>
> Pas possible hélas...

La plus mauvaise réponse à cette fausse question que l'industrie ait
trouvé jusqu'alors est Java et son bytecode.

Bob qui Trolle a écrit :

> La plus mauvaise réponse à cette fausse question que l'industrie ait
> trouvé jusqu'alors est Java et son bytecode.

J'ai pas compris.

--
Delf

Delf wrote:
> Bob qui Trolle a écrit :
>
>> La plus mauvaise réponse à cette fausse question que l'industrie ait
>> 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.

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...
>
> Pour avoir la liste:
> cpp -dM /dev/null

ça fait des années que je la cherche celle là !

Merci :-)

Bob qui Trolle a écrit :

> 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

À (at) Mon, 03 Apr 2006 17:03:05 +0200,
Delf <none@none.org> écrivait (wrote):
> 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/>

Paul Gaborit wrote:

>
> À (at) Mon, 03 Apr 2006 17:03:05 +0200,
> Delf <none@none.org> écrivait (wrote):
>> 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/

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!


--
Jérémy JUST <jeremy_just@netcourrier.com>

Jérémy JUST a écrit :

> 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 ? =)

--
Delf

Delf wrote:
> Jérémy JUST a écrit :
>
>> 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 ? =)
>
Ha oi : ça apporte des emplois à des jeunes programmeurs, ce qui est
vachement bien, même s'il faut les dépolluer après.

Bob qui Trolle a écrit :

> Ha oi : ça apporte des emplois à des jeunes programmeurs, ce qui est
> vachement bien, même s'il faut les dépolluer après.

J'attendais une telle réponse x)
Heureusement qu'il n'y a pas bcp de codeurs binaires...

--
Delf

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-bsd.php
manu@netbsd.org

Delf wrote:

> Jérémy JUST a écrit :
>
>> 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 ? =)

Puisqu'on est parti pour troller, regarde plutôt Ruby.

Emmanuel Dreyfus a écrit :

> Le cahier de l'admin BSD 2eme ed. est dans toutes les
> bonnes librairies

Y at-il un support PDF ?

--
Delf

Le Thu, 06 Apr 2006 08:56:12 +0200, Delf écrivit:
> > Le cahier de l'admin BSD 2eme ed. est dans toutes les
> > bonnes librairies
> Y at-il un support PDF ?

Où est le diff avec la première édition ?

Arnaud.
--
Perso: http://launay.org/blog/
Hébergement: http://www.nocworld.com/

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.

> Où est le diff avec la première édition ?

Avec le PDF.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org