est ce que je peux prendre n'importe quelle distrib linux, compiler, et
ca va marcher sur toutes les autres ?
ou il faudra que je compile sur chaque distrib où je veux que ca marche ?
--
Il parait que JC a dit qu'il n'y avait pas de plan B ...
---> Ne craignez pas d'avoir des remords après avoir voté NON, puisque
c'est sans incidence !
est ce que je peux prendre n'importe quelle distrib linux, compiler, et ca va marcher sur toutes les autres ?
Non.
Tout d'abord, il y a le probleme des processeurs, du code compile va fonctionner uniquement sur le processeur pour lequel il a ete compile et ceux qui sont compatibles. Tu indiques par ailleurs que tu fais de l'Ada, je suppose avec GNAT (je ne connais pas d'autres compilateurs Ada pour Linux), tu as les options de gcc qui permettent de controler separement le jeu d'instruction choisi (ce qui limite la compatibilite) et le processeur pour lequel le code est optimise (les combinaisons d'instructions seront choisies pour ce processeur la, les autres processeurs disposant du jeu d'instruction choisi auront peut-etre une code non optimal, mais ils pouront l'executer).
Il y a ensuite les bibliotheques dynamiques utilisees. Pour certaines c'est relativement facile d'imposer aux utilisateurs d'avoir la bonne version, pour d'autres (la libc par exemple), c'est pas facile du tout. Deux solutions: lier statiquement tout ou compiler sur la distribution la plus vieille (la libc est normalement compatible en ascendant et les distributions fournissent des versions plus anciennes de certaines lib)
Il y a la version du noyau qui pose parfois probleme. A nouveau, il y a generalement moins de difficultes a compiler sur qqch de vieux et faire tourner sur du neuf que l'inverse.
Enfin, suivant ce que tu fais il y a un tas de choses qui peuvent differer entre les distributions, cela va des scripts de demarrage, aux shells disponibles, etc...
C'est possible d'avoir un executable qui fonctionnent sur differentes distributions, ca necessite quand meme de tester et parfois d'adapter un peu.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Thomas <fantome.forums.tDeContes@free.fr> writes:
je veux faire une application multiplateformes
est ce que je peux prendre n'importe quelle distrib linux, compiler, et
ca va marcher sur toutes les autres ?
Non.
Tout d'abord, il y a le probleme des processeurs, du code compile va
fonctionner uniquement sur le processeur pour lequel il a ete compile
et ceux qui sont compatibles. Tu indiques par ailleurs que tu fais de
l'Ada, je suppose avec GNAT (je ne connais pas d'autres compilateurs
Ada pour Linux), tu as les options de gcc qui permettent de controler
separement le jeu d'instruction choisi (ce qui limite la
compatibilite) et le processeur pour lequel le code est optimise (les
combinaisons d'instructions seront choisies pour ce processeur la, les
autres processeurs disposant du jeu d'instruction choisi auront
peut-etre une code non optimal, mais ils pouront l'executer).
Il y a ensuite les bibliotheques dynamiques utilisees. Pour certaines
c'est relativement facile d'imposer aux utilisateurs d'avoir la bonne
version, pour d'autres (la libc par exemple), c'est pas facile du
tout. Deux solutions: lier statiquement tout ou compiler sur la
distribution la plus vieille (la libc est normalement compatible en
ascendant et les distributions fournissent des versions plus anciennes
de certaines lib)
Il y a la version du noyau qui pose parfois probleme. A nouveau, il y
a generalement moins de difficultes a compiler sur qqch de vieux et
faire tourner sur du neuf que l'inverse.
Enfin, suivant ce que tu fais il y a un tas de choses qui peuvent
differer entre les distributions, cela va des scripts de demarrage,
aux shells disponibles, etc...
C'est possible d'avoir un executable qui fonctionnent sur differentes
distributions, ca necessite quand meme de tester et parfois d'adapter
un peu.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
est ce que je peux prendre n'importe quelle distrib linux, compiler, et ca va marcher sur toutes les autres ?
Non.
Tout d'abord, il y a le probleme des processeurs, du code compile va fonctionner uniquement sur le processeur pour lequel il a ete compile et ceux qui sont compatibles. Tu indiques par ailleurs que tu fais de l'Ada, je suppose avec GNAT (je ne connais pas d'autres compilateurs Ada pour Linux), tu as les options de gcc qui permettent de controler separement le jeu d'instruction choisi (ce qui limite la compatibilite) et le processeur pour lequel le code est optimise (les combinaisons d'instructions seront choisies pour ce processeur la, les autres processeurs disposant du jeu d'instruction choisi auront peut-etre une code non optimal, mais ils pouront l'executer).
Il y a ensuite les bibliotheques dynamiques utilisees. Pour certaines c'est relativement facile d'imposer aux utilisateurs d'avoir la bonne version, pour d'autres (la libc par exemple), c'est pas facile du tout. Deux solutions: lier statiquement tout ou compiler sur la distribution la plus vieille (la libc est normalement compatible en ascendant et les distributions fournissent des versions plus anciennes de certaines lib)
Il y a la version du noyau qui pose parfois probleme. A nouveau, il y a generalement moins de difficultes a compiler sur qqch de vieux et faire tourner sur du neuf que l'inverse.
Enfin, suivant ce que tu fais il y a un tas de choses qui peuvent differer entre les distributions, cela va des scripts de demarrage, aux shells disponibles, etc...
C'est possible d'avoir un executable qui fonctionnent sur differentes distributions, ca necessite quand meme de tester et parfois d'adapter un peu.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Bastien Durel
Thomas wrote:
In article (Dans l'article) , Jérémy JUST wrote (écrivait) : l'idée c'est de savoir si je peux faire un seul binaire, pour redhat et pour mandrake par exemple
Si c'est sur le même type de CPU (au hasard, x86), et que tu n'utilises pas
d'optimisations particulières qui seraient liées à un type de CPU particulier (set d'instructions P4 par exemple), pas de problème.
-- Bastien Durel.
Thomas wrote:
In article (Dans l'article)
<20050524232436.5d1c8bb1@norbert.inapg.inra.fr>,
Jérémy JUST <jeremy_just@netcourrier.com> wrote (écrivait) :
l'idée c'est de savoir si je peux faire un seul binaire, pour redhat et
pour mandrake par exemple
Si c'est sur le même type de CPU (au hasard, x86), et que tu n'utilises pas
d'optimisations particulières qui seraient liées à un type de CPU particulier
(set d'instructions P4 par exemple), pas de problème.
In article (Dans l'article) , Jérémy JUST wrote (écrivait) : l'idée c'est de savoir si je peux faire un seul binaire, pour redhat et pour mandrake par exemple
Si c'est sur le même type de CPU (au hasard, x86), et que tu n'utilises pas
d'optimisations particulières qui seraient liées à un type de CPU particulier (set d'instructions P4 par exemple), pas de problème.
-- Bastien Durel.
Bastien Durel
Thomas wrote:
In article (Dans l'article) , Jérémy JUST wrote (écrivait) : l'idée c'est de savoir si je peux faire un seul binaire, pour redhat et pour mandrake par exemple
Si c'est sur le même type de CPU (au hasard, x86), et que tu n'utilises pas
d'optimisations particulières qui seraient liées à un type de CPU particulier (set d'instructions P4 par exemple), pas de problème. À condition, bien sûr, de ne pas utiliser de choses trop récentes, comme les nouvelles fonctionnalités du noyau 2.6 si tu veux pouvoir faire tourner le binaire sur des machines avec un noyau 2.4
-- Bastien Durel.
Thomas wrote:
In article (Dans l'article)
<20050524232436.5d1c8bb1@norbert.inapg.inra.fr>,
Jérémy JUST <jeremy_just@netcourrier.com> wrote (écrivait) :
l'idée c'est de savoir si je peux faire un seul binaire, pour redhat et
pour mandrake par exemple
Si c'est sur le même type de CPU (au hasard, x86), et que tu n'utilises pas
d'optimisations particulières qui seraient liées à un type de CPU particulier
(set d'instructions P4 par exemple), pas de problème.
À condition, bien sûr, de ne pas utiliser de choses trop récentes, comme les
nouvelles fonctionnalités du noyau 2.6 si tu veux pouvoir faire tourner le
binaire sur des machines avec un noyau 2.4
In article (Dans l'article) , Jérémy JUST wrote (écrivait) : l'idée c'est de savoir si je peux faire un seul binaire, pour redhat et pour mandrake par exemple
Si c'est sur le même type de CPU (au hasard, x86), et que tu n'utilises pas
d'optimisations particulières qui seraient liées à un type de CPU particulier (set d'instructions P4 par exemple), pas de problème. À condition, bien sûr, de ne pas utiliser de choses trop récentes, comme les nouvelles fonctionnalités du noyau 2.6 si tu veux pouvoir faire tourner le binaire sur des machines avec un noyau 2.4
-- Bastien Durel.
Paul Gaborit
À (at) Tue, 24 May 2005 23:15:15 +0200, Thomas écrivait (wrote):
on va dire que si j'ai besoin de juste une version mac os x + une bsd + une linux + une windows, ca ira
Faudra recompiler, mais ce n'est pas vraiment un soucis.
ben la diference c'est quand meme qu'il faut installer 15 linux ou 1 seul ! (c'est pour un logiciel proprietaire)
Si vous voulez produire des binaires, il vous faudra les fabriquer et les tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas des systèmes, ce sont des familles de systèmes). Il vous faudra donc bien installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus vous voulez vous assurer que ça marche sur différentes versions d'un même système (par exemple Windows 2000, 2003 et XP, MacOS X 10.3 et 10.4, FreeBSD 4.11, 5.3, 5.4, etc.) il vous faudra sûrement les installer et tester (voire reconfigurer/recompiler) à chaque fois.
Forcément, il faudra écrire ou utiliser du code portable.
aucun pb, c'est de l'ada :-)
Et alors ? Si votre programme a une quelconque interaction avec son environnement alors il y a risque d'incompatibilité... Ce n'est pas lié au langage de développement.
(et si en plus je peux en avoir une seule linux + bsd ...)
Rien qu'entre Net, Free ou OpenBSD les binaires sont incompatibles.
merci pour l'info
Certains OS (dont les *BSD) possèdent des couches de compatibilités binaires avec d'autres OS : cela permet, en théorie, de faire fonctionner un binaire conçu pour Linux (par exemple) sur un système FreeBSD (toujours par exemple). Mais pour être sûr du coup, il faut bien évidemment passer de la théorie à la pratique et donc tester la chose à chaque fois.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 24 May 2005 23:15:15 +0200,
Thomas <fantome.forums.tDeContes@free.fr> écrivait (wrote):
on va dire que si j'ai besoin de juste une version mac os x + une bsd
+ une linux + une windows, ca ira
Faudra recompiler, mais ce n'est pas vraiment un soucis.
ben la diference c'est quand meme qu'il faut installer 15 linux ou 1
seul !
(c'est pour un logiciel proprietaire)
Si vous voulez produire des binaires, il vous faudra les fabriquer et les
tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas des
systèmes, ce sont des familles de systèmes). Il vous faudra donc bien
installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus vous voulez
vous assurer que ça marche sur différentes versions d'un même système (par
exemple Windows 2000, 2003 et XP, MacOS X 10.3 et 10.4, FreeBSD 4.11, 5.3,
5.4, etc.) il vous faudra sûrement les installer et tester (voire
reconfigurer/recompiler) à chaque fois.
Forcément, il
faudra écrire ou utiliser du code portable.
aucun pb, c'est de l'ada :-)
Et alors ? Si votre programme a une quelconque interaction avec son
environnement alors il y a risque d'incompatibilité... Ce n'est pas lié au
langage de développement.
(et si en plus je peux en avoir une seule linux + bsd ...)
Rien qu'entre Net, Free ou OpenBSD les binaires sont incompatibles.
merci pour l'info
Certains OS (dont les *BSD) possèdent des couches de compatibilités binaires
avec d'autres OS : cela permet, en théorie, de faire fonctionner un binaire
conçu pour Linux (par exemple) sur un système FreeBSD (toujours par
exemple). Mais pour être sûr du coup, il faut bien évidemment passer de la
théorie à la pratique et donc tester la chose à chaque fois.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 24 May 2005 23:15:15 +0200, Thomas écrivait (wrote):
on va dire que si j'ai besoin de juste une version mac os x + une bsd + une linux + une windows, ca ira
Faudra recompiler, mais ce n'est pas vraiment un soucis.
ben la diference c'est quand meme qu'il faut installer 15 linux ou 1 seul ! (c'est pour un logiciel proprietaire)
Si vous voulez produire des binaires, il vous faudra les fabriquer et les tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas des systèmes, ce sont des familles de systèmes). Il vous faudra donc bien installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus vous voulez vous assurer que ça marche sur différentes versions d'un même système (par exemple Windows 2000, 2003 et XP, MacOS X 10.3 et 10.4, FreeBSD 4.11, 5.3, 5.4, etc.) il vous faudra sûrement les installer et tester (voire reconfigurer/recompiler) à chaque fois.
Forcément, il faudra écrire ou utiliser du code portable.
aucun pb, c'est de l'ada :-)
Et alors ? Si votre programme a une quelconque interaction avec son environnement alors il y a risque d'incompatibilité... Ce n'est pas lié au langage de développement.
(et si en plus je peux en avoir une seule linux + bsd ...)
Rien qu'entre Net, Free ou OpenBSD les binaires sont incompatibles.
merci pour l'info
Certains OS (dont les *BSD) possèdent des couches de compatibilités binaires avec d'autres OS : cela permet, en théorie, de faire fonctionner un binaire conçu pour Linux (par exemple) sur un système FreeBSD (toujours par exemple). Mais pour être sûr du coup, il faut bien évidemment passer de la théorie à la pratique et donc tester la chose à chaque fois.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Rakotomandimby (R12y) Mihamina
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit :
il vous faudra les fabriquer et les tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas des systèmes, ce sont des familles de systèmes). Il vous faudra donc bien installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus vous voulez vous assurer que ça marche sur différentes versions d'un même système (par exemple Windows 2000, 2003 et XP, MacOS X 10.3 et 10.4, FreeBSD 4.11, 5.3, 5.4, etc.) il vous faudra sûrement les installer et tester (voire reconfigurer/recompiler) à chaque fois.
J'allais le lui suggérer, mais j'ai eu peur qu'il me rétorque que ce sont justement des binaires destinés à l'équipe de test. Car effectivement, il peut etre le developpeur et il peut y avoir une couche de testeurs entre lui et le final user.
En tout cas, nous, on envisage ça.
Forcément, il faudra écrire ou utiliser du code portable. aucun pb, c'est de l'ada :-)
Et alors ? Si votre programme a une quelconque interaction avec son
environnement alors il y a risque d'incompatibilité... Ce n'est pas lié au langage de développement.
C'est lié à la conformité du code quant aux standards, et même au compilateur.
Certains OS (dont les *BSD) possèdent des couches de compatibilités binaires avec d'autres OS
Oui. Mais sur le poste de l'user final il faudrait installer cette "couche", ce qui n'est pas focément pratique.
Mais je voulais rajouter, pour thomas, que faire du propriétaire n'implique pas cacher son code. Il me semblait que Solaris10 était propriétaire à un moment mais son code source était disponible. Il suffit de mentionner les restrictions dans la Licence du logiciel.
Il me semble aussi que Qmail est dans la même situation. Ce n'est psa un logiciel libre, mais les sources sont disponibles.
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit :
il vous faudra les fabriquer et les
tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas
des systèmes, ce sont des familles de systèmes). Il vous faudra donc
bien installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus
vous voulez vous assurer que ça marche sur différentes versions d'un
même système (par exemple Windows 2000, 2003 et XP, MacOS X 10.3 et
10.4, FreeBSD 4.11, 5.3, 5.4, etc.) il vous faudra sûrement les installer
et tester (voire reconfigurer/recompiler) à chaque fois.
J'allais le lui suggérer, mais j'ai eu peur qu'il me rétorque que
ce sont justement des binaires destinés à l'équipe de test.
Car effectivement, il peut etre le developpeur et il peut y avoir une
couche de testeurs entre lui et le final user.
En tout cas, nous, on envisage ça.
Forcément, il
faudra écrire ou utiliser du code portable.
aucun pb, c'est de l'ada :-)
Et alors ? Si votre programme a une quelconque interaction avec son
environnement alors il y a risque d'incompatibilité... Ce n'est pas
lié au langage de développement.
C'est lié à la conformité du code quant aux standards, et même au
compilateur.
Certains OS (dont les *BSD) possèdent des couches de compatibilités
binaires avec d'autres OS
Oui. Mais sur le poste de l'user final il faudrait installer cette
"couche", ce qui n'est pas focément pratique.
Mais je voulais rajouter, pour thomas, que faire du propriétaire
n'implique pas cacher son code. Il me semblait que Solaris10 était
propriétaire à un moment mais son code source était disponible. Il
suffit de mentionner les restrictions dans la Licence du logiciel.
Il me semble aussi que Qmail est dans la même situation. Ce n'est psa un
logiciel libre, mais les sources sont disponibles.
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit :
il vous faudra les fabriquer et les tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas des systèmes, ce sont des familles de systèmes). Il vous faudra donc bien installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus vous voulez vous assurer que ça marche sur différentes versions d'un même système (par exemple Windows 2000, 2003 et XP, MacOS X 10.3 et 10.4, FreeBSD 4.11, 5.3, 5.4, etc.) il vous faudra sûrement les installer et tester (voire reconfigurer/recompiler) à chaque fois.
J'allais le lui suggérer, mais j'ai eu peur qu'il me rétorque que ce sont justement des binaires destinés à l'équipe de test. Car effectivement, il peut etre le developpeur et il peut y avoir une couche de testeurs entre lui et le final user.
En tout cas, nous, on envisage ça.
Forcément, il faudra écrire ou utiliser du code portable. aucun pb, c'est de l'ada :-)
Et alors ? Si votre programme a une quelconque interaction avec son
environnement alors il y a risque d'incompatibilité... Ce n'est pas lié au langage de développement.
C'est lié à la conformité du code quant aux standards, et même au compilateur.
Certains OS (dont les *BSD) possèdent des couches de compatibilités binaires avec d'autres OS
Oui. Mais sur le poste de l'user final il faudrait installer cette "couche", ce qui n'est pas focément pratique.
Mais je voulais rajouter, pour thomas, que faire du propriétaire n'implique pas cacher son code. Il me semblait que Solaris10 était propriétaire à un moment mais son code source était disponible. Il suffit de mentionner les restrictions dans la Licence du logiciel.
Il me semble aussi que Qmail est dans la même situation. Ce n'est psa un logiciel libre, mais les sources sont disponibles.
-- Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Marc Boyer
Rakotomandimby (R12y) Mihamina wrote:
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit : Mais je voulais rajouter, pour thomas, que faire du propriétaire n'implique pas cacher son code. Il me semblait que Solaris10 était propriétaire à un moment mais son code source était disponible.
Hein ? Ou ça ? Ca m'intéresserait beaucoup.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Rakotomandimby (R12y) Mihamina wrote:
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit :
Mais je voulais rajouter, pour thomas, que faire du propriétaire
n'implique pas cacher son code. Il me semblait que Solaris10 était
propriétaire à un moment mais son code source était disponible.
Hein ? Ou ça ?
Ca m'intéresserait beaucoup.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit : Mais je voulais rajouter, pour thomas, que faire du propriétaire n'implique pas cacher son code. Il me semblait que Solaris10 était propriétaire à un moment mais son code source était disponible.
Hein ? Ou ça ? Ca m'intéresserait beaucoup.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Rakotomandimby (R12y) Mihamina
( Wed, 25 May 2005 08:55:49 +0000 ) Marc Boyer :
Rakotomandimby (R12y) Mihamina wrote:
Il me semblait que Solaris10 était propriétaire à un moment mais son code source était disponible. Hein ? Ou ça ?
Ca m'intéresserait beaucoup.
Aller... une "partie" de son code. (j'ai oublié "une partie", excuse) Et puis en cherchant mieux (j'ai vu qu') il est encore propriétaire.
Marc Boyer --
Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
( Wed, 25 May 2005 08:55:49 +0000 ) Marc Boyer :
Rakotomandimby (R12y) Mihamina wrote:
Il me semblait que Solaris10 était propriétaire à un moment
mais son code source était disponible.
Hein ? Ou ça ?
Ca m'intéresserait beaucoup.
Aller... une "partie" de son code. (j'ai oublié "une partie", excuse)
Et puis en cherchant mieux (j'ai vu qu') il est encore propriétaire.
Marc Boyer
--
Mirroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Il me semblait que Solaris10 était propriétaire à un moment mais son code source était disponible. Hein ? Ou ça ?
Ca m'intéresserait beaucoup.
Aller... une "partie" de son code. (j'ai oublié "une partie", excuse) Et puis en cherchant mieux (j'ai vu qu') il est encore propriétaire.
Marc Boyer --
Mirroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
Nicolas George
Jean-Marc Bourguet wrote in message :
Deux solutions: lier statiquement
J'insiste à nouveau : attention aux licences. Déjà la libc : il existe actuellement à ma connaissance quatre libc en circulation pour Linux : la glibc, la libc5, la µClibc et la dietlibc. La dietlibc est sous GPL : il est interdit de distribuer une application propriétaire liée avec elle.
Les autres sont principalement ou totalement dout LGPL : on a le droit de distribuer une application propriétaire liée avec, mais il est exigé que le changement de la bibliothèque soit possible. Ce qui implique : soit liaison dynamique, soit sources distribuées (ou à la rigueur les fichiers objets).
Évidemment, il est toujours possible de se passer de la libc, en réécrivant soi-même les appels systèmes. Mais c'est plutôt fastidieux.
Jean-Marc Bourguet wrote in message
<pxbbr6z3i7s.fsf@news.bourguet.org>:
Deux solutions: lier statiquement
J'insiste à nouveau : attention aux licences. Déjà la libc : il existe
actuellement à ma connaissance quatre libc en circulation pour Linux : la
glibc, la libc5, la µClibc et la dietlibc. La dietlibc est sous GPL : il est
interdit de distribuer une application propriétaire liée avec elle.
Les autres sont principalement ou totalement dout LGPL : on a le droit de
distribuer une application propriétaire liée avec, mais il est exigé que le
changement de la bibliothèque soit possible. Ce qui implique : soit liaison
dynamique, soit sources distribuées (ou à la rigueur les fichiers objets).
Évidemment, il est toujours possible de se passer de la libc, en réécrivant
soi-même les appels systèmes. Mais c'est plutôt fastidieux.
J'insiste à nouveau : attention aux licences. Déjà la libc : il existe actuellement à ma connaissance quatre libc en circulation pour Linux : la glibc, la libc5, la µClibc et la dietlibc. La dietlibc est sous GPL : il est interdit de distribuer une application propriétaire liée avec elle.
Les autres sont principalement ou totalement dout LGPL : on a le droit de distribuer une application propriétaire liée avec, mais il est exigé que le changement de la bibliothèque soit possible. Ce qui implique : soit liaison dynamique, soit sources distribuées (ou à la rigueur les fichiers objets).
Évidemment, il est toujours possible de se passer de la libc, en réécrivant soi-même les appels systèmes. Mais c'est plutôt fastidieux.
Thomas
In article (Dans l'article) <d71nro$lda$, Nicolas George <nicolas$ wrote (écrivait) :
Jean-Marc Bourguet wrote in message :
Deux solutions: lier statiquement
J'insiste à nouveau : attention aux licences. Déjà la libc : il existe actuellement à ma connaissance quatre libc en circulation pour Linux : la glibc, la libc5, la µClibc et la dietlibc. La dietlibc est sous GPL : il est interdit de distribuer une application propriétaire liée avec elle.
Les autres sont principalement ou totalement dout LGPL : on a le droit de distribuer une application propriétaire liée avec, mais il est exigé que le changement de la bibliothèque soit possible. Ce qui implique : soit liaison dynamique, soit sources distribuées (ou à la rigueur les fichiers objets).
Évidemment, il est toujours possible de se passer de la libc, en réécrivant soi-même les appels systèmes. Mais c'est plutôt fastidieux.
merci à tous pour les précisions :-)
-- Il parait que JC a dit qu'il n'y avait pas de plan B ... ---> Ne craignez pas d'avoir des remords après avoir voté NON, puisque c'est sans incidence !
In article (Dans l'article) <d71nro$lda$1@biggoron.nerim.net>,
Nicolas George <nicolas$george@salle-s.org> wrote (écrivait) :
Jean-Marc Bourguet wrote in message
<pxbbr6z3i7s.fsf@news.bourguet.org>:
Deux solutions: lier statiquement
J'insiste à nouveau : attention aux licences. Déjà la libc : il existe
actuellement à ma connaissance quatre libc en circulation pour Linux : la
glibc, la libc5, la µClibc et la dietlibc. La dietlibc est sous GPL : il est
interdit de distribuer une application propriétaire liée avec elle.
Les autres sont principalement ou totalement dout LGPL : on a le droit de
distribuer une application propriétaire liée avec, mais il est exigé que le
changement de la bibliothèque soit possible. Ce qui implique : soit liaison
dynamique, soit sources distribuées (ou à la rigueur les fichiers objets).
Évidemment, il est toujours possible de se passer de la libc, en réécrivant
soi-même les appels systèmes. Mais c'est plutôt fastidieux.
merci à tous pour les précisions :-)
--
Il parait que JC a dit qu'il n'y avait pas de plan B ...
---> Ne craignez pas d'avoir des remords après avoir voté NON, puisque
c'est sans incidence !
In article (Dans l'article) <d71nro$lda$, Nicolas George <nicolas$ wrote (écrivait) :
Jean-Marc Bourguet wrote in message :
Deux solutions: lier statiquement
J'insiste à nouveau : attention aux licences. Déjà la libc : il existe actuellement à ma connaissance quatre libc en circulation pour Linux : la glibc, la libc5, la µClibc et la dietlibc. La dietlibc est sous GPL : il est interdit de distribuer une application propriétaire liée avec elle.
Les autres sont principalement ou totalement dout LGPL : on a le droit de distribuer une application propriétaire liée avec, mais il est exigé que le changement de la bibliothèque soit possible. Ce qui implique : soit liaison dynamique, soit sources distribuées (ou à la rigueur les fichiers objets).
Évidemment, il est toujours possible de se passer de la libc, en réécrivant soi-même les appels systèmes. Mais c'est plutôt fastidieux.
merci à tous pour les précisions :-)
-- Il parait que JC a dit qu'il n'y avait pas de plan B ... ---> Ne craignez pas d'avoir des remords après avoir voté NON, puisque c'est sans incidence !
Thomas
In article (Dans l'article) , "Rakotomandimby (R12y) Mihamina" wrote (écrivait) :
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit :
il vous faudra les fabriquer et les tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas des systèmes, ce sont des familles de systèmes). Il vous faudra donc bien installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus vous voulez vous assurer que ça marche sur différentes versions d'un même système (par exemple Windows 2000, 2003 et XP, MacOS X 10.3 et 10.4, FreeBSD 4.11, 5.3, 5.4, etc.) il vous faudra sûrement les installer et tester (voire reconfigurer/recompiler) à chaque fois.
J'allais le lui suggérer, mais j'ai eu peur
bah faut pas avoir peur comme ca :-D
qu'il me rétorque que ce sont justement des binaires destinés à l'équipe de test. Car effectivement, il peut etre le developpeur et il peut y avoir une couche de testeurs entre lui et le final user.
non, je suis le seul informaticien
et, dans ce cas, l'equipe de testeurs ets employée de la société ? donc ca veut dire que de toutes facons il faut que la société s'equipe
En tout cas, nous, on envisage ça.
qui c'est "nous" ? :-)
Mais je voulais rajouter, pour thomas, que faire du propriétaire n'implique pas cacher son code.
oui, mais pour mon patron, ce qui est important c'est pas d'appeler ca "proprietaire", mais de cacher son code ;-D
ah si tu pouvais lui expliquer qu'on peut gagner de l'argent avec du logiciel libre :-) (oui parce que, pour moi par contre, c'est encore bien mieux si c'est libre que simplement "readable-source" ;-) )
-- Il parait que JC a dit qu'il n'y avait pas de plan B ... ---> Ne craignez pas d'avoir des remords après avoir voté NON, puisque c'est sans incidence !
In article (Dans l'article)
<pan.2005.05.25.08.49.34.186854@etu.univ-orleans.fr>,
"Rakotomandimby (R12y) Mihamina"
<mihamina.rakotomandimby@etu.univ-orleans.fr> wrote (écrivait) :
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit :
il vous faudra les fabriquer et les
tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas
des systèmes, ce sont des familles de systèmes). Il vous faudra donc
bien installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus
vous voulez vous assurer que ça marche sur différentes versions d'un
même système (par exemple Windows 2000, 2003 et XP, MacOS X 10.3 et
10.4, FreeBSD 4.11, 5.3, 5.4, etc.) il vous faudra sûrement les installer
et tester (voire reconfigurer/recompiler) à chaque fois.
J'allais le lui suggérer, mais j'ai eu peur
bah faut pas avoir peur comme ca :-D
qu'il me rétorque que
ce sont justement des binaires destinés à l'équipe de test.
Car effectivement, il peut etre le developpeur et il peut y avoir une
couche de testeurs entre lui et le final user.
non, je suis le seul informaticien
et, dans ce cas, l'equipe de testeurs ets employée de la société ?
donc ca veut dire que de toutes facons il faut que la société s'equipe
En tout cas, nous, on envisage ça.
qui c'est "nous" ? :-)
Mais je voulais rajouter, pour thomas, que faire du propriétaire
n'implique pas cacher son code.
oui, mais pour mon patron, ce qui est important c'est pas d'appeler ca
"proprietaire", mais de cacher son code ;-D
ah si tu pouvais lui expliquer qu'on peut gagner de l'argent avec du
logiciel libre :-)
(oui parce que, pour moi par contre, c'est encore bien mieux si c'est
libre que simplement "readable-source" ;-) )
--
Il parait que JC a dit qu'il n'y avait pas de plan B ...
---> Ne craignez pas d'avoir des remords après avoir voté NON, puisque
c'est sans incidence !
In article (Dans l'article) , "Rakotomandimby (R12y) Mihamina" wrote (écrivait) :
( Wed, 25 May 2005 10:00:15 +0200 ) Paul Gaborit :
il vous faudra les fabriquer et les tester un par un pour chacun des systèmes (Linux comme BSD ne sont pas des systèmes, ce sont des familles de systèmes). Il vous faudra donc bien installer 15(?) Linux, 3 BSD, un Mac OSX et un Windows. Si en plus vous voulez vous assurer que ça marche sur différentes versions d'un même système (par exemple Windows 2000, 2003 et XP, MacOS X 10.3 et 10.4, FreeBSD 4.11, 5.3, 5.4, etc.) il vous faudra sûrement les installer et tester (voire reconfigurer/recompiler) à chaque fois.
J'allais le lui suggérer, mais j'ai eu peur
bah faut pas avoir peur comme ca :-D
qu'il me rétorque que ce sont justement des binaires destinés à l'équipe de test. Car effectivement, il peut etre le developpeur et il peut y avoir une couche de testeurs entre lui et le final user.
non, je suis le seul informaticien
et, dans ce cas, l'equipe de testeurs ets employée de la société ? donc ca veut dire que de toutes facons il faut que la société s'equipe
En tout cas, nous, on envisage ça.
qui c'est "nous" ? :-)
Mais je voulais rajouter, pour thomas, que faire du propriétaire n'implique pas cacher son code.
oui, mais pour mon patron, ce qui est important c'est pas d'appeler ca "proprietaire", mais de cacher son code ;-D
ah si tu pouvais lui expliquer qu'on peut gagner de l'argent avec du logiciel libre :-) (oui parce que, pour moi par contre, c'est encore bien mieux si c'est libre que simplement "readable-source" ;-) )
-- Il parait que JC a dit qu'il n'y avait pas de plan B ... ---> Ne craignez pas d'avoir des remords après avoir voté NON, puisque c'est sans incidence !
