scanf et GTC - Page 1

Bonjour,

J'ai GTC on-calc. J'ai essayé d'écrire scanf(), mais GTC ne le reconnait pas. Pourquoi?

Merci d'avance,
ProgVal

Parce que scanf n'est pas une fonction dy système d'exploitation et GTC ne l'a pas implanté (elle est assez grosse comme fonction et augmenterait ton programme de quelques kilos).

Martial Demolins (./3) :
La glibc elle sert à quoi, elle contient toutes ces fonctions en statique ? tous les print*, scan* etc... Ca veut dire qu'on a pas d'oevrhead quand on utilise ces fonctions sur PC ?

La glibc est en général une librairie dynamique contenant ces fonctions, et qui est liée à ton programme (Identique à une lib kernel, sauf qu'elle est présente partout).

Beurk.

(cross)

thi > stoi qui est beurk

la glibc dynamique elle est chargée en un seul exemplaire en ram et elle est mappée dans l'espace de chaque processus.

Si elle est statique, elle est recopiée dans chaque binaire.

pas la peine de troller, ça se décide au cas par cas selon le besoin et le nb de binaires. En général on y gagne pour une distro linux, même si la glibc en question contient plein de code inutile, parce que ça a rien a voir avec une TI

martial: pour simplifier la glibc c'est la tigcclib du pc (en très très gros, hein...)

libc.a devrait être présent dans /usr/lib
Si c'est le cas, tu l'as en 'nostub'.

huhu

Bah bah voilà, linux est mal foutu. Aucune cohérence. Ils peuvent pas centraliser cette bibliothèque dans un dossier système, ? Quel gaspillage de place !

Thibaut (./11) :
Bah bah voilà, linux est mal foutu. Aucune cohérence. Ils peuvent pas centraliser cette bibliothèque dans un dossier système, ? Quel gaspillage de place !

Je comprends pas du tout ce que tu veux dire. lib.c.so existe, est dans un répertoire système (/usr/lib) et est utilisé par tous les programmes sauf ceux qui veulent être en static pur (qui utilise libc.a) (à savoir aucun programme ou presque).

s/présente/utilisée/

#thibaut#

D'accord. Faut dire que Linux est bordélique. Je comprends pas l'organisation des fichiers des programmes. Sous Windows, tout est centralisé dans Program Files. Sous Linux, on trouve les programmes dans plusieurs dossiers différents.

Martial Demolins (./14) :
Suffisamment bien foutu en tout cas pour pas se taper des centaines de milliers de virus...

Ca arrivera un jour sur Linux

Thibaut (./18) :
Sous Windows, tout est centralisé dans Program Files.

Tu oublies windows...

Sinon:

/dev: Les devices
/etc: Les fichiers de configuration (et les scripts de lancement)
/bin: Les outils consoles
/sbin: Les outils consoles root
/proc: Les processus + quelques infos systèmes.
/sys: Configuration système
/usr: Le système
/usr/bin: les programmes de ta distribution
/usr/sbin: les programmes de ta distribution root
/usr/include: les fichiers include
/lib /usr/lib: les librairies dynamiques
/usr/local: les fichiers locaux hors distribution (là où tu installes tes programmes non fournis par ta distribution)
/var: Des fichiers utilisés par les services.
/ media ou /mnt: les points de montages des cdrom/disques dur/...
/boot: le noyau et tout ce qu'il faut pour démarrer.
/root: le HOME de root
/home ou /users: les HOME des utilisateurs.
/var/tmp ou /tmp: les fichiers temporaires (Perso j'ai un lien symbolique de /var/tmp dans /tmp)
/opt: Les programmes tiers.

./18 Au contraire, je trouve que sous linux l'arborescence du système de fichiers est très pratique : les applis sont toutes dans /usr/bin, la configuration se gère à partir du répertoire /etc, les répertoires des utilisateurs sont dans /home, du coup on peut bien séparer toutes ces choses et on s'y retrouve bien plus facilement que sous windows où tout est n'importe où et nulle part (base de registres) en même temps... Où il y a certains programmes qui ne "s'installent pas", où il faut sans arrêt utiliser la recherche de fichiers pour retrouver ses affaires. Depuis que j'utilise Linux je n'utilise quaisment plus la recherche de fichiers (en fait, j'utilise plutôt grep pour chercher dans le contenu des fichiers).

Sous Windows, tout est centralisé dans Program Files.

Comme l'indique PpHd, tu oublies le principal endroit où sont les fichiers pous Windows: Windows lui-même...
%WINDIR% ne vaut pas Program Files.

Et +1 sur toute la ligne de ./20.
Tu es rarement embêté avec les problèmes de PATH sous Linux (à moins d'installer toi-même des outils non prévus pour à des endroits bizarres, mais à ce moment-là, c'est de ta faute, pas celle du système).

Perso j'installe tous mes programmes (depuis les sources) dans /opt/programme puis je fais des liens symboliques de ce qu'il faut /usr/local
Ca marche super bien pour la maintenance et l'intégration dans le système.

Je suis d'accord

J'ai comme l'impression que Thibaut critique un peu à tout va Linux, en écrivant souvent n'importe quoi...
Autre exemple, topics/2-108312-pourquoi-linux-cest-bien/19#546 (critique de l'outil alors que c'est lui, utilisateur, qui ne sait pas faire - et que si les backports ne sont pas configurés par défaut, c'est parce qu'il y a une raison !).

c'est souvent difficile de reconnaitre que PEBKAC (moi le premier, parfois)

En effet, c'est difficile.
Blâmer l'outil m'est arrivé cette semaine, avec Doxygen, alors qu'il ne faisait que ce que je lui avais demandé... enfin, ce que j'avais apparemment oublié, c'est de mettre quelques PREDEFINED pour contourner des limitations connues de Doxygen lui-même, comme le fait de ne pas skipper purement et simplement les __attribute__.
A la limite, on ne lui demande pas de comprendre les __attribute__... mais ça serait sympa qu'il arrête de faire n'importe quoi quand il rencontre des trucs aussi courants qu' "__attribute__((aligned(x)))" dans du code (pas rare...) qui utilise directement les attributes, sans les wrapper dans une macro nommée par exemple ALIGNED.
(Traiter les __attribute__ est le sujet d'un bug report déjà ancien, mais pas résolu)


Enfin bref, comme je ne l'avais pas paramétré comme il faut pour contourner ses limitations, Doxygen parsait n'importe quoi, et le résultat visible était que non seulement certaines fonctions n'apparaissaient pas dans les callgraphs, mais en plus, il y avait des fonctions nommées "if", "for", "switch" et "__volatile__"



Même si j'en avais relativement envie, j'ai évité d'utiliser "PEBKAC" pour répondre hier au post que j'ai mis en lien dans ./23
Etre blessant, même si on a raison, n'est pas vraiment la bonne façon de se faire comprendre.

C'est quoi ce truc encore. Expliquez-moi, vous les geeks pour qui tout est facile et pour qui c'est jamais le système qui est en tort

On va essayer

> Faut dire que Linux est bordélique.
Non seulement ça n'a rien à faire dans une discussion constructive, mais en plus, tu as mis ça _au début_ des propos... et tu le présentes comme un truc objectif, puisque tu as négligé de mettre une notion d'opinion du style "je pense que".

> Je comprends pas l'organisation des fichiers des programmes.
Tu as le droit de ne pas la comprendre, mais elle est plutôt plus uniforme et simple que sous Windows

> Sous Windows, tout est centralisé dans Program Files.
Nan, on a expliqué pourquoi. Déjà, tu as oublié la base, Windows...
Ensuite, presque tous les installeurs permettent de paramétrer l'endroit où on installe le programme. Ce qui ne facilite pas la recherche des applications.
Sous *nix, c'est installé à un endroit standardisé.

> Sous Linux, on trouve les programmes dans plusieurs dossiers différents.
Pas plus et pas moins que sous Windows: chaque programme a son dossier (souvent dans /usr/share). C'est juste que c'est à un endroit différent...
Linux n'est pas Windows, MacOS n'est pas Windows, etc. C'est tout.
Sous Linux, on sépare en général le programme principal dans /bin ou /usr/bin, les librairies dont il a besoin dans /usr/lib et /usr/share/..., et les données dont il a besoin dans /usr/share/nomduprogramme/.

(posté avec lag)

25>le truc c'est qu'il faut chercher à se documenter le plus possible avant de cracher sur un programme

Et PEBKAC, ça veut dire quoi ?

t'aimes pas google toi

problem exists between keyboard and chair