Help Lib comment faire? - Page 1

Bon voila, j'ai plusieurs questions de newb en C:

Comment crée t'on une dll?
Comment crée t'on une lib statique?

Pour la 2eme question:
j'ai lu le super tuto de Squale, mais il ne m'avance pas beaucoup.
J'ai en effet vu dans les sources de TIGCC.Lib que l'on peut mettre plusieurs fonctions ensembles (fonctions relatives).
Exemples; Grays.h, dans le fichier, il y a un asm ou il y a plusieurs fonctions GrayOn GrayOff (ce qui contredit le tuto de squale?§/!).
Donc comment faire si je veux pas exemple faire une lib statique, comme tigcc?

Derniere question: que dois je choisir: Format dll ou format statique?

La "concurrence" t'aurait-elle pousée à te décider enfin à simplifier la tâche de tes utilisateurs ?

Alors :


- mettre chaque fonction dans un fichier .c à part. La raison : seuls les fichiers objet effectivement utilisés seront recopiés dans le programme final. Si tu mets plusieurs fonctions dans le même fichier C, ils se retrouveront dans le même fichier objet et ne pourront pas être séparés par le linker. Seule exception : des fonctions qui sont TOUJOURS utilisés ensemble.

- définir _GENERIC_ARCHIVE (qui s'utilise comme SAVE_SCREEN, OPTIMIZE_ROM_CALLS ou USE_KERNEL) au début de chaque fichier .c (pour que le fichier C soit compilé comme du _nostub, mais que _nostub ne soit pas exporté). L'option désactive aussi des trucs comme OPTIMIZE_ROM_CALLS qui ne peuvent pas être dans des librairies statiques à usage général.

Si tu crées des fichiers en assembleur, programme comme du _nostub qui ne dépend pas d'une valeur précise en a5 par exemple, et n'exporte pas _nostub (pour permettre l'usage de la librairie statique dans les programmes pour kernel).

- Dans Project / Options, choisis : "Target: Function Archive (.a)".

- Au début de chaque fichier en assembleur, rajoute:
* section ".data" si c'est du A68k
* .data si c'est du GNU as
Même si c'est du code. Il n'y a qu'une seule section pour code et données pour les programmes en RAM sur TI-89/92+/V200.


Explications copyright 2002 Kevin Kofler.

Oky merci
Mais si j'utilise un variable globale pour toutes mes fonctions,je le fait comment? je les mets dans mon header?

Tu la mets dans un fichier C à elle toute seule, et tu la définis comme extern dans tous les autres.

Ok thx

sinon pour la question sur les dll?

ok thx.

heu, j'ai lu la doc, mais j'ai pas compris la diff entre:
_DLL_call_attr
et _DLL_call (

si qqn pouvais m'expliquer

Comme l'indique le nom, _DLL_call_attr permet de rajouter des attributs.

D'ailleurs, le support des DLLs n'a pas été prévu pour des débutants en C, mais pour des programmeurs expérimentés qui écrivent des programmes >64 KO. C'est pour ça que la documentation est assez technique (et que tu ne la comprends donc pas entièrement comme le message #7 le montre). La version DLL de _X_Lib (< 10 KO) est vraiment un foutage de gueule!

Pas du tout

Puis en ce qui conserne le C.. je ne suis pas si débutant que ca... d'ailleur gs tools depassais les 64 Ko si je ne l'avais pas partager en plusieurs fichiers....

d'ailleur dans mon bouquin de 1000s page sur le c / c++ ne parle pas de call_attr.. alors je ne suis pas sur que ce soit du a des lacunes en C!
Faut pas chercher de arguments aussi bas

__attribute__, c'est du GNU C, donc si tu ne comprends pas la différence entre une macro qui te permet de mettre des __attribute__ et une macro qui a un argument en moins et qui ne te permet pas d'en mettre, c'est que tu as des lacunes en GNU C.

Et je répète que tu abuses le système de DLLs:

Now that we have explained why you might need to use external libraries, we specifically want to discourage their use for anything else. External (dynamic) libraries have been used quite often in the past to automate common tasks, like file access, graphics, compression, etc. This is not what we want to happen, otherwise there will be a different libraries for the same tasks, with a lot of incompatiblities between libraries and even between different versions of the same library. TIGCC provides the possibility to use static libraries (also known as function archives) for this purpose. In the IDE, you need to select the creation of a function archive in the project options; when using the command line compiler, you need to use the '-ar' switch. When using function archives, only the files which are needed are really included in the final program.
There is an exception to the rule that you should not create a dynamic library to make it available to others: If the library itself is very large, and a program will typically use a lot of its functions at the same time, client programs are likely to exceed the file size limit if it is provided as a static library. In this case, using a dynamic library really is the only possibility. An example is the FAT Library by the TI-Chess Team.

Je pense que je vais mettre un check dans la prochaine bêta qui vérifiera que le programme et la DLL dépassent 32 KO chacun.

...
Bien.. parce que tu crois que tu pouras imposer ton idéologie nostub a tout le monde? ce sera contourné en 2 3 mouvements...
De toute maniere t'auras pas besoin de faire ca...

Et puis de toute maniere Si vous voulez de bon jeux.. ce sera certainement pas avec extgraphlib que vous allez les faire.. donc faudra utiliser une lib annex comme genlib

Pfffff, alors si tu fais ça Kevin, ben laisse tomber ....

C NOTRE problème si on veut pas mettre à chaque fois les fonctions graphiques dans chaque programme les utilisant, et pas celui de la TIGCC_team !

Et oui...
Le projet TIGCC monte a la tete de certaine personne

vivement gtc lui au moins n'imposera pas (du moin sje l'espere) tel ou tel ideo..

Ouaip

Oui, mais que les choses soient quand même claires : si l'équipe TI-GCC a tort, c pas parce qu'elle impose un point de vue, c parce que son point de vue est erronné. Si effectivement les libs dynamiques étaient néfastes, ils auraient raison. Le problème est que les libs dynamiques, si elles étaient supportées par TI-GCC (càd avec une lib dynamique pour GrayOn(), printf(), etc... qui prendrait 5 ko max), réduiraient considérablement la taille des progs (sans parler du _nostub : un hello world tout bête avec SAVE_SCREEN est déjà plus gros en _nostub qu'en kernel )

Si j'ai le temps, j'incorporerais les fonctions de gray/etc... de TI-GCC dans la Virtual Machine de GT-Basic

Pollux a écrit :
Oui, mais que les choses soient quand même claires : si l'équipe TI-GCC a tort, c pas parce qu'elle impose un point de vue, c parce que son point de vue est erronné. Si effectivement les libs dynamiques étaient néfastes, ils auraient raison. Le problème est que les libs dynamiques, si elles étaient supportées par TI-GCC (càd avec une lib dynamique pour GrayOn(), printf(), etc... qui prendrait 5 ko max), réduiraient considérablement la taille des progs (sans parler du _nostub : un hello world tout bête avec SAVE_SCREEN est déjà plus gros en _nostub qu'en kernel )

Non. Puisque vous ne m'écoutez pas, moi, je vais citer Scott Noveck à la place:

> why bother writing something when you can probably get a dll with tons of routines in it already
Because "DLL Hell" is already an incredible mess on windows, it's already an incredible mess for kernel programs, and the last thing we need is a mess of dependencies for nostub programs, too. It might sound like a good idea for saving space in theory, but it never works out that way -- the space savings from using dynamic libraries will in fact be very small (almost negligible), users need to keep track of libraries, there are different and possibly incompatible versions of the libraries everywhere, and the run-time memory requirements go _way_ up (usually too much to load more than one DLL at once, even if we wanted to let you).

Et:

After hearing about XLib, I think I'll go back to heading the "Remove DLL support from TIGCC; anybody who needs it can read the FAT source" camp. Other than FAT, the only legitimate use of DLL's I've seen is Xeontech, and that doesn't use TIGCC's DLL support -- Mikel read how FAT did it and used that, just like I'm suggesting. Hopefully anyone skilled enough to figure out how FAT works will understand the consequences.
I applaud Zeljko for adding the DLL support, but I think it's too similar to adding full flash-writing support -- it has some legitimate uses, but it's too likely to be abused.

Voilà: donc c'est soit mon check de taille, soit on supprimera complètement le support des DLLs. Désolé.

EDIT: Parce que ce n'était pas vraiment clair: ceci n'est pas une décision définitive, mais un avertissement de ce qui risque de se passer, et une décision que j'aurais envie de prendre personnellement. Il est évident que je vais laisser Sebastian et Zeljko prendre la décision finale.

Là je ne dis rien à propos de la TIGCC team, Kevin, mais je n'en pense pas moins.

putain là c'est vraiment pour faire chier le monde, je vois pas d'autre raison ...

on va voir apparaitre des version crackée de tigcc si ça continue ...

c clair, c n'imp'...

c vraiment extremement sympathique pour TImad.. vraiment..

> it's already an incredible mess for kernel programs
du moment que les libs sont bien conçues, pas de pb (c pour ça qu'il faut centraliser la création de libs d'ailleurs)

Qui a eu des pb de compatibilité entre les différentes versions de genlib? pas moi...

> and the last thing we need is a mess of dependencies for nostub programs, too
ben c sûr ça revient à rapprocher le _nostub du kernel, donc forcément si on aime pas le kernel

> the space savings from using dynamic libraries will in fact be very small (almost negligible)
Totalement faux, sans compter la compatibilité lors des changements de HW/ROM
On a déjà fait bcp de débats là-dessus, on va pas y revenir...

> there are different and possibly incompatible versions of the libraries everywhere
D'où l'intérêt d'une gestion centralisée

> and the run-time memory requirements go _way_ up (usually too much to load more than one DLL at once, even if we wanted to let you)
vu l'accroissement de taille des progs nostub rien qu'avec le fait que la table des relocations a été conçue par des handicapés mentaux (ça reste en RAM ça ) et en comptant le fait qu'on pourrait enlever la table des relocations de la RAM en mode kernel, la différence de RAM est négligeable pour un gain substantiel d'archive...

Moi, je considère que ce n'est pas symathique de la part de TiMad de nous pondre une DLL de 8 KO malgré ce qui est dit dans notre documentation: donc soit il n'a pas lu la documentation, soit il fait exprès de nous embêter.

Vous faites chier avec votre dictature !
Vous vous croyez les maîtres de la programmation ?

Et puis attendez la décision définitive que je prendrai en accord avec Sebastian et Zeljko, pas tout seul, avant de vous acharner contre l'équipe entière.

Peu importe, GTC compile aussi sur PC. Si la TI-GCC team continue sa dictature, quitte à avoir des progs un peu moins optimisés en vitesse (pas en taille), je peux publier tout de suite GTC.exe (en plus la compilation est ultra rapide )

Pollux a écrit :
je peux publier tout de suite GTC.exe (en plus la compilation est ultra rapide )

vas-y te gene pas

(AT field dressé !)

vous n'av aucun respect pour le boulot des autres, c dommage..
enfin, perso de toutes façons asm+kernel+batch+ue powa, donc..

Pollux=>EXE : c cool, ça ! je savais pô

Pen^2
a écrit : vous n'av aucun respect pour le boulot des autres, c dommage..

Moi, je trouve que c'est TiMad qui n'a aucun respect pour notre boulot en l'abusant exprès (parce qu'il est dit exprès dans notre documentation que les DLLs ne sont pas faites pour ça). Je ne dirais rien si c'était une DLL de 32 KO (et qui utilise vraiment ces 32 KO!), mais une DLL de 8 KO, c'est vraiment abusé!

je doute qd meme qu'il ait fait ça "rien que pour vous embeter"