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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc Boyer
Le 03-04-2006, Delf a écrit :
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 ?
En quoi est-ce une question sur le langage C ? Est-ce que fr.comp.os.unix ne serait pas plus adapté ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 03-04-2006, Delf <none@none.org> a écrit :
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 ?
En quoi est-ce une question sur le langage C ?
Est-ce que fr.comp.os.unix ne serait pas plus adapté ?
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
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 ?
En quoi est-ce une question sur le langage C ? Est-ce que fr.comp.os.unix ne serait pas plus adapté ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Delf
En quoi est-ce une question sur le langage C ? Est-ce que fr.comp.os.unix ne serait pas plus adapté ?
Exact. Je reposte, merci.
-- Delf
En quoi est-ce une question sur le langage C ?
Est-ce que fr.comp.os.unix ne serait pas plus adapté ?
En quoi est-ce une question sur le langage C ? Est-ce que fr.comp.os.unix ne serait pas plus adapté ?
Exact. Je reposte, merci.
-- Delf
Antoine Leca
En news:44311ea3$0$9639$, Delf va escriure:
J'ai écris un programme C qui fonctionne sous Linux et *BSD.
Même machine ?
Ce programme contient des sections : #ifdef LINUX ... #endif // LINUX etc. car j'utilise des appels systèmes qui ne fonctionnent que selon l'OS.
Les dépendances à un système sont de deux types :
- les appels système et plus généralement tout ce qui est spécifique à un système ; normalement, on isole ce genre de code (par exemple dans une unité séparée, ce qui permet d'identifier facilement les tâches de maintenance, par exemple pour une nouvelle version). Cela ne concerne que le source.
- la dépendance à l'environnement d'exécution, en particulier la bibliothèque C ; ce qui se traduit par la nécessité de disposer pendant la compilation de l'arborescence xxx/include correspondant à la cible visée (et bien sûr qu'elle soit référencée par le compilateur, pour Gcc voir 'specs'); par la nécessité d'isoler les .o produits pour qu'ils ne se mélangent pas ; par la nécessité de disposer des fichiers de bibliothèques (.a or .so) correspondants pendant l'édition des liens. Cela ne concerne que le processus de compilation.
Comme on le voit, il faut bien disposer des environnements de programmation correspondant à tous les systèmes visés, mais il n'est point besoin d'exécuter le compilateur sur l'environnement visé.
L'installation d'un compilateur croisé, c'est la résolution du second problème. Le premier n'a en fait rien à voir (et il est plus simple d'installer un compilateur croisé pour compiler hello.c ou un programme portable à peine plus compliqué, que de se lancer tout de suite dans un source à géométrie variable).
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.
Bouh... Soit tu compiles pour le plus petit dénomimateur commun (genre 4.x), et tu vérifies que cela fonctionne avec la version récente (6.y), en tirant partie de la compatibilité ascendante. Soit tu abandonnes la vieille version : car il est probable que tu n'arriveras pas à maintenir longtemps une version complètement différente... De plus, si l'environnement d'exploitation est mis-à-jour, ton programme se plante... mauvais cela.
Si la différence se situe au niveau de l'interprétation de certains paramètres, il faut apprendre au code à réagir à la version en cours.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Bien sûr que non.
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 ?
Oui, mais c'est plus coton. Il y eut des tentatives variées de définitions d'interface plus ou moins communes (iBCS pour Intel ; aujourd'hui les machines *BSD/i386 savent exécuter un sous-ensemble intéressant de l'environnement Linux/i386). Clairement, il faut reposter ailleurs pour avoir des informations fiables.
Antoine
En news:44311ea3$0$9639$636a55ce@news.free.fr, Delf va escriure:
J'ai écris un programme C qui fonctionne sous Linux et *BSD.
Même machine ?
Ce programme contient des sections :
#ifdef LINUX
...
#endif // LINUX
etc.
car j'utilise des appels systèmes qui ne fonctionnent que selon l'OS.
Les dépendances à un système sont de deux types :
- les appels système et plus généralement tout ce qui est spécifique à un
système ; normalement, on isole ce genre de code (par exemple dans une unité
séparée, ce qui permet d'identifier facilement les tâches de maintenance,
par exemple pour une nouvelle version).
Cela ne concerne que le source.
- la dépendance à l'environnement d'exécution, en particulier la
bibliothèque C ; ce qui se traduit par la nécessité de disposer pendant la
compilation de l'arborescence xxx/include correspondant à la cible visée (et
bien sûr qu'elle soit référencée par le compilateur, pour Gcc voir 'specs');
par la nécessité d'isoler les .o produits pour qu'ils ne se mélangent pas ;
par la nécessité de disposer des fichiers de bibliothèques (.a or .so)
correspondants pendant l'édition des liens.
Cela ne concerne que le processus de compilation.
Comme on le voit, il faut bien disposer des environnements de programmation
correspondant à tous les systèmes visés, mais il n'est point besoin
d'exécuter le compilateur sur l'environnement visé.
L'installation d'un compilateur croisé, c'est la résolution du second
problème. Le premier n'a en fait rien à voir (et il est plus simple
d'installer un compilateur croisé pour compiler hello.c ou un programme
portable à peine plus compliqué, que de se lancer tout de suite dans un
source à géométrie variable).
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.
Bouh... Soit tu compiles pour le plus petit dénomimateur commun (genre 4.x),
et tu vérifies que cela fonctionne avec la version récente (6.y), en tirant
partie de la compatibilité ascendante. Soit tu abandonnes la vieille version
: car il est probable que tu n'arriveras pas à maintenir longtemps une
version complètement différente... De plus, si l'environnement
d'exploitation est mis-à-jour, ton programme se plante... mauvais cela.
Si la différence se situe au niveau de l'interprétation de certains
paramètres, il faut apprendre au code à réagir à la version en cours.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Bien sûr que non.
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 ?
Oui, mais c'est plus coton. Il y eut des tentatives variées de définitions
d'interface plus ou moins communes (iBCS pour Intel ; aujourd'hui les
machines *BSD/i386 savent exécuter un sous-ensemble intéressant de
l'environnement Linux/i386).
Clairement, il faut reposter ailleurs pour avoir des informations fiables.
J'ai écris un programme C qui fonctionne sous Linux et *BSD.
Même machine ?
Ce programme contient des sections : #ifdef LINUX ... #endif // LINUX etc. car j'utilise des appels systèmes qui ne fonctionnent que selon l'OS.
Les dépendances à un système sont de deux types :
- les appels système et plus généralement tout ce qui est spécifique à un système ; normalement, on isole ce genre de code (par exemple dans une unité séparée, ce qui permet d'identifier facilement les tâches de maintenance, par exemple pour une nouvelle version). Cela ne concerne que le source.
- la dépendance à l'environnement d'exécution, en particulier la bibliothèque C ; ce qui se traduit par la nécessité de disposer pendant la compilation de l'arborescence xxx/include correspondant à la cible visée (et bien sûr qu'elle soit référencée par le compilateur, pour Gcc voir 'specs'); par la nécessité d'isoler les .o produits pour qu'ils ne se mélangent pas ; par la nécessité de disposer des fichiers de bibliothèques (.a or .so) correspondants pendant l'édition des liens. Cela ne concerne que le processus de compilation.
Comme on le voit, il faut bien disposer des environnements de programmation correspondant à tous les systèmes visés, mais il n'est point besoin d'exécuter le compilateur sur l'environnement visé.
L'installation d'un compilateur croisé, c'est la résolution du second problème. Le premier n'a en fait rien à voir (et il est plus simple d'installer un compilateur croisé pour compiler hello.c ou un programme portable à peine plus compliqué, que de se lancer tout de suite dans un source à géométrie variable).
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.
Bouh... Soit tu compiles pour le plus petit dénomimateur commun (genre 4.x), et tu vérifies que cela fonctionne avec la version récente (6.y), en tirant partie de la compatibilité ascendante. Soit tu abandonnes la vieille version : car il est probable que tu n'arriveras pas à maintenir longtemps une version complètement différente... De plus, si l'environnement d'exploitation est mis-à-jour, ton programme se plante... mauvais cela.
Si la différence se situe au niveau de l'interprétation de certains paramètres, il faut apprendre au code à réagir à la version en cours.
Bref, je ne vais pas installer tous les OS pour compiler une source.
Bien sûr que non.
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 ?
Oui, mais c'est plus coton. Il y eut des tentatives variées de définitions d'interface plus ou moins communes (iBCS pour Intel ; aujourd'hui les machines *BSD/i386 savent exécuter un sous-ensemble intéressant de l'environnement Linux/i386). Clairement, il faut reposter ailleurs pour avoir des informations fiables.
Antoine
Delf
Même machine ?
Non. Mais essentiellement des x86. Seulement, je vais aussi devoir fournir des binaires pour les 64bits :`
Les dépendances à un système sont de deux types :
- les appels système et plus généralement tout ce qui est spécifique à un système ; normalement, on isole ce genre de code (par exemple dans une unité séparée, ce qui permet d'identifier facilement les tâches de maintenance, par exemple pour une nouvelle version). Cela ne concerne que le source.
Un peut comme les blocs #ifdef ... que j'ai utilisé ?
- la dépendance à l'environnement d'exécution, en particulier la bibliothèque C ; ce qui se traduit par la nécessité de disposer pendant la compilation de l'arborescence xxx/include correspondant à la cible visée (et bien sûr qu'elle soit référencée par le compilateur, pour Gcc voir 'specs'); par la nécessité d'isoler les .o produits pour qu'ils ne se mélangent pas ; par la nécessité de disposer des fichiers de bibliothèques (.a or .so) correspondants pendant l'édition des liens. Cela ne concerne que le processus de compilation.
En fait, mon problème se situe au niveau des libs auxquelles le binaire est lié(es ?).
Bouh... Soit tu compiles pour le plus petit dénomimateur commun (genre 4.x), et tu vérifies que cela fonctionne avec la version récente (6.y), en tirant partie de la compatibilité ascendante.
J'ai déjà effectué cette manipulation, sans succès sous FreeBSD. Cause, libc je crois, de mémoire.
Oui, mais c'est plus coton. Il y eut des tentatives variées de définitions d'interface plus ou moins communes (iBCS pour Intel ; aujourd'hui les machines *BSD/i386 savent exécuter un sous-ensemble intéressant de l'environnement Linux/i386).
Ca devient complexe là : Au pire, si un utilisateur veut le support pour va version de son OS, je lui transmet le source, il le compile et m'envoie une copie du binaire -> compilation distribuée manuelle :)
Merci pour ces éclaircissements.
-- Delf
Même machine ?
Non. Mais essentiellement des x86. Seulement, je vais aussi devoir
fournir des binaires pour les 64bits :`
Les dépendances à un système sont de deux types :
- les appels système et plus généralement tout ce qui est spécifique à un
système ; normalement, on isole ce genre de code (par exemple dans une unité
séparée, ce qui permet d'identifier facilement les tâches de maintenance,
par exemple pour une nouvelle version).
Cela ne concerne que le source.
Un peut comme les blocs #ifdef ... que j'ai utilisé ?
- la dépendance à l'environnement d'exécution, en particulier la
bibliothèque C ; ce qui se traduit par la nécessité de disposer pendant la
compilation de l'arborescence xxx/include correspondant à la cible visée (et
bien sûr qu'elle soit référencée par le compilateur, pour Gcc voir 'specs');
par la nécessité d'isoler les .o produits pour qu'ils ne se mélangent pas ;
par la nécessité de disposer des fichiers de bibliothèques (.a or .so)
correspondants pendant l'édition des liens.
Cela ne concerne que le processus de compilation.
En fait, mon problème se situe au niveau des libs auxquelles le binaire
est lié(es ?).
Bouh... Soit tu compiles pour le plus petit dénomimateur commun (genre 4.x),
et tu vérifies que cela fonctionne avec la version récente (6.y), en tirant
partie de la compatibilité ascendante.
J'ai déjà effectué cette manipulation, sans succès sous FreeBSD. Cause,
libc je crois, de mémoire.
Oui, mais c'est plus coton. Il y eut des tentatives variées de définitions
d'interface plus ou moins communes (iBCS pour Intel ; aujourd'hui les
machines *BSD/i386 savent exécuter un sous-ensemble intéressant de
l'environnement Linux/i386).
Ca devient complexe là : Au pire, si un utilisateur veut le support
pour va version de son OS, je lui transmet le source, il le compile et
m'envoie une copie du binaire -> compilation distribuée manuelle :)
Non. Mais essentiellement des x86. Seulement, je vais aussi devoir fournir des binaires pour les 64bits :`
Les dépendances à un système sont de deux types :
- les appels système et plus généralement tout ce qui est spécifique à un système ; normalement, on isole ce genre de code (par exemple dans une unité séparée, ce qui permet d'identifier facilement les tâches de maintenance, par exemple pour une nouvelle version). Cela ne concerne que le source.
Un peut comme les blocs #ifdef ... que j'ai utilisé ?
- la dépendance à l'environnement d'exécution, en particulier la bibliothèque C ; ce qui se traduit par la nécessité de disposer pendant la compilation de l'arborescence xxx/include correspondant à la cible visée (et bien sûr qu'elle soit référencée par le compilateur, pour Gcc voir 'specs'); par la nécessité d'isoler les .o produits pour qu'ils ne se mélangent pas ; par la nécessité de disposer des fichiers de bibliothèques (.a or .so) correspondants pendant l'édition des liens. Cela ne concerne que le processus de compilation.
En fait, mon problème se situe au niveau des libs auxquelles le binaire est lié(es ?).
Bouh... Soit tu compiles pour le plus petit dénomimateur commun (genre 4.x), et tu vérifies que cela fonctionne avec la version récente (6.y), en tirant partie de la compatibilité ascendante.
J'ai déjà effectué cette manipulation, sans succès sous FreeBSD. Cause, libc je crois, de mémoire.
Oui, mais c'est plus coton. Il y eut des tentatives variées de définitions d'interface plus ou moins communes (iBCS pour Intel ; aujourd'hui les machines *BSD/i386 savent exécuter un sous-ensemble intéressant de l'environnement Linux/i386).
Ca devient complexe là : Au pire, si un utilisateur veut le support pour va version de son OS, je lui transmet le source, il le compile et m'envoie une copie du binaire -> compilation distribuée manuelle :)
Merci pour ces éclaircissements.
-- Delf
Emmanuel Delahaye
Les dépendances à un système sont de deux types :
- les appels système et plus généralement tout ce qui est spécifique à un système ; normalement, on isole ce genre de code (par exemple dans une unité séparée, ce qui permet d'identifier facilement les tâches de maintenance, par exemple pour une nouvelle version). Cela ne concerne que le source.
Un peut comme les blocs #ifdef ... que j'ai utilisé ?
Oui, mais pas au milieu du code d'application. Uniquement dans des modules séparés 'de compatibilité' comme l'a bien expliqué Antoine.
-- A+
Emmanuel Delahaye
Les dépendances à un système sont de deux types :
- les appels système et plus généralement tout ce qui est spécifique à un
système ; normalement, on isole ce genre de code (par exemple dans une
unité
séparée, ce qui permet d'identifier facilement les tâches de maintenance,
par exemple pour une nouvelle version).
Cela ne concerne que le source.
Un peut comme les blocs #ifdef ... que j'ai utilisé ?
Oui, mais pas au milieu du code d'application. Uniquement dans des
modules séparés 'de compatibilité' comme l'a bien expliqué Antoine.
- les appels système et plus généralement tout ce qui est spécifique à un système ; normalement, on isole ce genre de code (par exemple dans une unité séparée, ce qui permet d'identifier facilement les tâches de maintenance, par exemple pour une nouvelle version). Cela ne concerne que le source.
Un peut comme les blocs #ifdef ... que j'ai utilisé ?
Oui, mais pas au milieu du code d'application. Uniquement dans des modules séparés 'de compatibilité' comme l'a bien expliqué Antoine.
-- A+
Emmanuel Delahaye
Delf
Oui, mais pas au milieu du code d'application. Uniquement dans des modules séparés 'de compatibilité' comme l'a bien expliqué Antoine.
Oui, ça c'est une chose que je dois changer.
-- Delf
Oui, mais pas au milieu du code d'application. Uniquement dans des
modules séparés 'de compatibilité' comme l'a bien expliqué Antoine.
