Java, les outils libres et tutti quanti - Page 4

onur (./69) :

Ce message apparaît quand MinGW a été compilé avec un préfixe sur D:, il fonctionne quand-même sur C:, mais il te donne cette erreur à la con. J'ai un patch dans TIGCC:

2004-01-04  Kevin Kofler  <Kevin@tigcc.ticalc.org>

	* cppdefaults.c (struct cpp_include_defaults): Disable hardcoded prefixes.
	    (GCC_INCLUDE_DIR, GCC_INCLUDE_DIR_LEN): Disable hardcoded prefix.
	* gcc.c (STANDARD_EXEC_PREFIX, STANDARD_STARTFILE_PREFIX, TOOLDIR_BASE_PREFIX,
	         STANDARD_BINDIR_PREFIX, standard_exec_prefix, standard_exec_prefix_1,
	         md_exec_prefix, md_startfile_prefix, md_startfile_prefix_1,
	         standard_startfile_prefix, standard_startfile_prefix_1,
	         standard_startfile_prefix_2, tooldir_base_prefix, tooldir_prefix,
	         standard_bindir_prefix): Disable.
	    (struct static_specs): Disable md_exec_prefix, md_startfile_prefix,
	                           md_startfile_prefix_1 and startfile_prefix_spec.
	    (int warn_std_ptr): Disable unused variable.
	    (process_command): Don't use environment variables. Don't hardcode any prefix at
	                       compile time.
	    (main): Likewise.

pour éviter ce problème (ça concerne aussi les cross-compilateurs sur host MinGW). Il faudrait que tu signales ce problème à la personne qui crée le binaire, au minimum elle pourrait utiliser un préfixe sur C:. (Le patch TIGCC tel quel n'est probablement pas viable, il dépend du fait que tigcc passe le bon préfixe à gcc avec le switch -B, donc on n'a pas besoin de la gestion de préfixes de GCC.)

Le problème, c'est que la logique de GCC, c'est qu'il est configuré pour un préfixe donné, genre /usr, et un paquetage binaire s'installe toujours dans ce même préfixe. Il n'est pas conçu à la base pour les OS pourris qui n'ont pas de layout standard du système de fichiers. Il y a un certain support pour le relogement dans un nouveau préfixe parce que MinGW en a besoin, justement, mais il essaie quand-même d'abord d'accéder au préfixe pour lequel il a été compilé, et si c'est un lecteur CD, l'OS met ce dialogue à la con.

Zephyr (./77) :
une petite idée du temps qu'il faut pour recompiler GCC, et de la partie de plaisir que c'est quand on est sous Windows ?

C'est dans l'ordre de grandeur d'une heure (ça change en fonction de la version de l'OS (c'est plus rapide sous un NT qu'un 9x/Me), de la vitesse du processeur, des frontends/langages choisis etc.).

onur (./85) :
(et malheureusement on n'a pas le choix de faire dans un autre langage)

Ben, il faut trouver une manière d'évader la JVM. Mais à chaque fois que quelqu'un en trouve une, tout le monde est là pour gueuler "trou de sécurité, il faut patcher vos téléphones immédiatement!!!!!!!!1111111!!!!!!!!!!!!!!" et personne pour sortir des applications qui utilisent la faille de manière intelligente. (Et avec tout ce que je peux reprocher à l'iPhone, eux au moins, ils ont une communauté de développeurs qui a le courage d'attaquer ce genre de protections, contrairement aux téléphones Java qui n'ont l'air d'attirer que les fanatiques de Java pour lesquels essayer de faire tourner un autre langage serait une hérésie ou un aimant à virus.)

GCC, en général, il est compilé avec la directive -Os, -O0, -O1/2/3 ?

-O2 par défaut; en revanche, TIGCC est compilé avec -Os, sauf pour le RPM, qui utilise les RPM_OPT_FLAGS de Fedora, donc entre autres -O2.

Pourquoi tu ne fais pas en sorte de rendre TIGCC plus rapide ?

-Os = moins à télécharger, vous vous plaignez toujours qu'il y a trop à télécharger, faut choisir.

vince (./79) :
Il existe un os libre, codé en java ? je ne crois pas...

Si, si, mais pas totalement fonctionnel http://en.wikipedia.org/wiki/Jnode

Kevin : TIGCC n'est pas énorme. Je préfère passer 2 minutes de plus pour télécharger TIGCC le jour où je l'installe, et gagner 10 minutes par journée de travail les mois suivants.

Kevin Kofler (./91) :
Le problème, c'est que la logique de GCC, c'est qu'il est configuré pour un préfixe donné, genre /usr, et un paquetage binaire s'installe toujours dans ce même préfixe. Il n'est pas conçu à la base pour les OS pourris qui n'ont pas de layout standard du système de fichiers.

C'est vrai que c'est trop pourri de permettre d'installer ses applications n'importe où et pas seulement à un endroit fixé à la compilation

Moins à télécharger, et après tu nous parles de KDE et de GTK ?

Brunni (./98) :

Kevin Kofler (./91) :
Le problème, c'est que la logique de GCC, c'est qu'il est configuré pour un préfixe donné, genre /usr, et un paquetage binaire s'installe toujours dans ce même préfixe. Il n'est pas conçu à la base pour les OS pourris qui n'ont pas de layout standard du système de fichiers.

C'est vrai que c'est trop pourri de permettre d'installer ses applications n'importe où et pas seulement à un endroit fixé à la compilation

franchement, si on commence à accorder ce genre de libertés à un programme, où va-ton ? #cc#
(en plus, tout le monde sait que tous les binaires sous linux sont dans /bin... euh /usr/bin... euh /usr/local/bin... euh /sbin.. ah non, c'est dans /opt/bin en fait

Mais non les binaires sont dans ~/.usr/bin/ !

chez moi, c'est plutôt dans ~/.local/bin

Brunni (./98) :
C'est vrai que c'est trop pourri de permettre d'installer ses applications n'importe où et pas seulement à un endroit fixé à la compilation

Ce qui est pourri est que le fait de permettre d'installer ses applications n'importe où nécessite de permettre des chemins d'accès différents. L'organisation interne de tes disques et partitions est un détail d'implémentation que tes programmes ne sont pas censés devoir connaître, des mountpoints standard qui sont pareil sur tous les systèmes, qu'ils soient composés d'un seul disque avec une seule partition ou de 5 disques à 2 partitions chacune, sont beaucoup plus pratiques.

Flanker (./100) :
(en plus, tout le monde sait que tous les binaires sous linux sont dans /bin... euh /usr/bin... euh /usr/local/bin... euh /sbin.. ah non, c'est dans /opt/bin en fait

Les binaires d'une application conforme à la norme FHS et packagée correctement sont dans /usr/bin. Les répertoires sbin ne sont utilisés que pour les applications d'administration système qui nécessitent l'accès root. /bin est pour une liste bien précise d'applications de base spécifiée dans la norme FHS (genre bash) et pour les logiciels système qui doivent fonctionner quand /usr n'est pas encore monté, tout le reste n'a rien à faire en dehors de /usr. Et /usr/local et /opt sont interdits aux logiciels packagés correctement. (Oui, /usr/local/tigcc est aussi contraire à la FHS, le RPM s'installera dans /usr/tigcc dans le futur.)

Kevin Kofler (./91) :
Ben, il faut trouver une manière d'évader la JVM. Mais à chaque fois que quelqu'un en trouve une, tout le monde est là pour gueuler "trou de sécurité, il faut patcher vos téléphones immédiatement!!!!!!!!1111111!!!!!!!!!!!!!!"

Bah en même temps c'est pas faux c'est bien un trou de sécurité qui permet de de déverouiller une limitation. Tout comme ça a été le cas pour Fargo, HWPatch, ... pour les TI. Personnellement sur un portable faire le choix de tout verrouiller est un avis que je ne partage pas mais qui me semble se défendre étant donné que le public ciblé est quand même l'anti-geek de base, et que la stabilité/sécurité passent avant tout.

et personne pour sortir des applications qui utilisent la faille de manière intelligente. (Et avec tout ce que je peux reprocher à l'iPhone, eux au moins, ils ont une communauté de développeurs qui a le courage d'attaquer ce genre de protections, contrairement aux téléphones Java qui n'ont l'air d'attirer que les fanatiques de Java pour lesquels essayer de faire tourner un autre langage serait une hérésie ou un aimant à virus.)

. La difficulté pour les Java Phone classique, c'est qu'il ont une durée de vie courte et un nombre énorme de modèles différente avec des JVM également différentes ce qui rend difficile de former une vraie communauté, sauf justement pour certain modèle comme l'iPhone. En moins de deux ans, j'ai vu défiler des centaines de modèles de téléphone et on était loin de les posséder tous. Pourtant des bugs visiblement dus à des buffers overflow, on en à vu quelques sans même les chercher.

Thibaut (./97) :
Kevin : TIGCC n'est pas énorme. Je préfère passer 2 minutes de plus pour télécharger TIGCC le jour où je l'installe, et gagner 10 minutes par journée de travail les mois suivants.

Bah tu peux télécharger les sources, passer une heure à essayer de les compiler avec les options de ton choix pour ensuite gagner 10 minutes par journée de travail les mois suivants.

Brunni (./83) :
Donc du coup sauf cas hyper particuliers (système de menus vraiment mal codé, mais ça m'étonne parce qu'à part attendre une touche et gérer le curseur il n'y a rien à faire)

Sauf que s'il n'y a aucune considération pour l'optimisation, "gérer le curseur" ça peut être reparcourir plein de structures de données compliquées, réafficher des trucs (si possible plusieurs fois ), etc... Demande à TI comment ils font

Uther (./104) :

Kevin Kofler (./91) :
Ben, il faut trouver une manière d'évader la JVM. Mais à chaque fois que quelqu'un en trouve une, tout le monde est là pour gueuler "trou de sécurité, il faut patcher vos téléphones immédiatement!!!!!!!!1111111!!!!!!!!!!!!!!"

Bah en même temps c'est pas faux c'est bien un trou de sécurité qui permet de de déverouiller une limitation. Tout comme ça a été le cas pour Fargo, HWPatch, ... pour les TI. Personnellement sur un portable faire le choix de tout verrouiller est un avis que je ne partage pas mais qui me semble se défendre étant donné que le public ciblé n'est quand même l'anti-geek de base, et que la stabilité/sécurité passent avant tout.

C'est surtout que l'impact d'une faille sur un téléphone est infiniment plus grave qu'une pauvre calculatrice...

onur : Oui mais autant en faire profiter tout le monde. Y'a plus grand monde en 56k... Et c'est quoi 2 minutes de téléchargement supplémentaires si l'on gagne du temps après...
Kevin, comment tu justifies le choix de -Os ? (contraire aux versions officielles de GCC d'ailleurs)

Au fait, pourquoi les paquets (et les logiciels au moment de l'exécution) ne peuvent pas savoir où se trouvent les différents répertoires du système sous Linux ? Il y a bien un symbole pour Home (~), qui permet de faire abstraction du chemin réel. Il n'y a pas de symboles pour les autres (share, bin, etc) ?

onur (./106) :
Bah tu peux télécharger les sources, passer une heure à essayer de les compiler avec les options de ton choix pour ensuite gagner 10 minutes par journée de travail les mois suivants.

J'ai déjà essayé de télécharger les source pour les recompiler pensant qu'il s'agissait d'uin simple ./configure && make && make install.
Le readme parle entre autre de version particulière de GCC à récupérer puis patcher. J'ai pas eu le courage.

Kevin Kofler (./103) :

Brunni (./98) :
C'est vrai que c'est trop pourri de permettre d'installer ses applications n'importe où et pas seulement à un endroit fixé à la compilation

Ce qui est pourri est que le fait de permettre d'installer ses applications n'importe où nécessite de permettre des chemins d'accès différents. L'organisation interne de tes disques et partitions est un détail d'implémentation que tes programmes ne sont pas censés devoir connaître, des mountpoints standard qui sont pareil sur tous les systèmes, qu'ils soient composés d'un seul disque avec une seule partition ou de 5 disques à 2 partitions chacune, sont beaucoup plus pratiques.

Ca c'est une philosophie qui est défendue par UNIX, mais à mon avis ça peut être discutable (hé oui il n'y a pas qu'UNIX dans la vie, même si Windows est le seul OS à ne pas être basé dessus).
D'un côté on a l'avantage que chaque "répertoire" (bin, usr, etc.) pourrait être sur une autre partition / autre mémoire, ça peut être pas mal pour les systèmes embarqués. De l'autre on voit clairement où est quoi, on a une partition système (faut pas rêver le grub que t'as installé sur ton MBR te permet de booter depuis une partition, et pas depuis autre chose), et éventuellement d'autres partitions pour les données ou les OS alternatifs. C'est plus pratique dans le cas où les choses changent peu (disques durs fixes par exemple) et finalement si les programmes s'adaptent et font bien les choses plutôt que de coder C:\Windows en dur () il n'y a aucun problème.
Et à la limite je pourrais remplacer mes dossiers locaux (C:\Users, C:\Windows, ...) par des liens symboliques pour faire "black box" comme sous Unix, mais heu...
Bref c'est tout à fait discutable. Dans le cas de Windows, l'idéal serait un nommage un peu meilleur que C, D, E, comme par exemple sur PSP: flash0:/... pour la première partition système, ms0:/ pour la première Memory Stick, etc.

Brunni (./110) :
Et à la limite je pourrais remplacer mes dossiers locaux (C:\Users, C:\Windows, ...) par des liens symboliques pour faire "black box" comme sous Unix, mais heu...

Mais de toute façon, un programme Windows qui n'est pas codé avec les pieds utilise les variables d'environnement kivonbien (%APPDATA%, %HOMEPATH%, %WINDIR%, %SYSTEMROOT%, ... )

Folco (./111) :

Brunni (./110) :
Ca c'est une philosophie qui est défendue par UNIX, mais à mon avis ça peut être discutable

J'aime cette mentalité qui consiste à dire "il y a un truc éprouvé qui fait ça, mais moi chui un r3b3lz et ya mieux tout'fasson" sans même avoir réfléchi sur tous les aspects de la question, et en oubliant de préciser que quelque soit le choix fait, ce sera en emportant avec un certain nombre d'avantages au détriments d'autres.

Il n'y a aucun avantage à faire du code non flexible... Surtout que la manipulation de noms de fichiers est loin d'être un facteur suffisant pour ralentir une application...
C'est moche, c'est pas flexible, c'est pas portable, c'est tout.

Folco (./111) :

Brunni (./110) :
Ca c'est une philosophie qui est défendue par UNIX, mais à mon avis ça peut être discutable

J'aime cette mentalité qui consiste à dire "il y a un truc éprouvé qui fait ça, mais moi chui un r3b3lz et ya mieux tout'fasson" sans même avoir réfléchi sur tous les aspects de la question, et en oubliant de préciser que quelque soit le choix fait, ce sera en emportant avec un certain nombre d'avantages au détriments d'autres.

Je n'ai pas dit le contraire
Maintenant ça veut dire que UNIX est parfait, qu'on ne le remette pas en question? Soit, moi je veux juste dire que ça peut être discutable, en faisant "l'avocat du diable". Parce qu'en fait je n'ai pas vraiment de préférence, si ce n'est peut-être celui de UNIX pour la scalabilité (mais ce n'est pas mon problème sur ma machine de travail) et Windows pour la vue d'ensemble de mes HD.

Personne ne répond... bon, j'ai du dire une betise...
Alors pourquoi il y a une totale incompatibilité entre les distributions si le fait que les chemins changent ne dérange pas ?

./115 > Ben parce que le fait que les chemins changent dérange justement...
Et non y'a pas de "symbole" prédéfini pour les répertoires, tu as les variables d'environnement PATH et LD_LIBRARY_PATH, et c'est à peu près tout, car tout le reste est non standard (et encore je crois que LD_LIBRARY_PATH n'est pas utilisé par fedora (pas standard !), du moins c'était le cas sur la version que j'ai utilisé... En fait la variable était reconnue mais vide par défaut )

Mais pourquoi ils ne mettent pas des symboles dans le noyau, pour gérer automatiquement les différentes organisations des répertoires ???

GoldenCrystal (./116) :
et encore je crois que LD_LIBRARY_PATH n'est pas utilisé par fedora (pas standard !), du moins c'était le cas sur la version que j'ai utilisé... En fait la variable était reconnue mais vide par défaut )

Je crois que c'est le cas sur la plupart des distributions que j'ai essayé. Pas uniquement la Fedora.

GoldenCrystal (./113) :
Il n'y a aucun avantage à faire du code non flexible...

Il ne s'agit pas de faire du code non flexible mais de ne pas exiger du code flexible... Il y aura *forcément* des programmes buggés qui utiliseront des chemins en dur, donc si on veut résoudre ce problème il n'y a que deux solutions vraiment fiables : casser toute la compatibilité avec les chemins en dur (prendre des chemins aléatoires par exemple ), ou au contraire la garantir.

Thibaut (./117) :
Mais pourquoi ils ne mettent pas des symboles dans le noyau, pour gérer automatiquement les différentes organisations des répertoires ???

C'est le cas sous les OS bien pensés tels que Windows (%SystemDrive%, %SystemRoot%, %AppData%, %HomePath%, %Temp%, ...).
(mince je parle comme Kevin!)