..:: Topic des Codeurs Couche-Tard [0] ::..

Pylades · Le 29/04/2010, à 11:56

Oui, je sais.

J’ai cherché, et je suis tombé sur un HOWTO qui a l’air pas mal.
http://tldp.org/HOWTO/Program-Library-H … aries.html

grim7reaper · Le 29/04/2010, à 12:07

Mouais c'est bien, mais pas besoin d'anglais pour une fois car cette ressource n'apporte rien de plus que celles qui existent en français (après si c'est pour bosser ton anglais OK, mais tu peux trouver l'équivalent en français).

Au pire, tu avais aussi le post que j'avais fait pour tshirtman .

Dernière modification par grim7reaper (Le 29/04/2010, à 12:08)

Pylades · Le 29/04/2010, à 12:12

Ben, j’ai pris le premier truc que j’ai trouvé, il se trouve que c’était en anglais. Et heureusement, c’est pas dans un anglais trop compliqué, donc ça me va.

Sinon, j’avais oublié que tu avais donné des lignes lorsque tu as répondu à tshirtman, je vais voir ça.

grim7reaper · Le 29/04/2010, à 12:18

Bah l'anglais technique c'est cool et c'est relativement simple (que ça soit en info ou en bio, [nostalgie]Raaah la bio ça me manque un peu quand même[/nostalgie])

Bah attend je te le ressors (par si tu fouille dans le TDCT tu n'as pas fini), je l'ai mis de côté pour une remise en forme future (plus ou moins éloigné).

grim7reaper a écrit :

Pour compiler une bibliothèque en dynamique, la démarche générale est

# Creation des fichiers objets, le -fPIC est pour créer du code relogeable (PIC = Position Independant Code).
gcc -c -fPIC *.c
# Creation de la bibliothèque, le -Wl c'est pour passer des options à l'éditeur de liens
# Ici on lui donne le soname (c'est une chaîne de caractère stocké dans la bibliothèque qui l'identifie, c'est pour les versions je crois). «man ld» pour plus d'info.
# Bien sur, les noms des bibliothèque doivent comporter le numéro majeur, mineur, voire révision pour bien faire les choses.
gcc -shared -o talib.so -Wl, -soname, talib.so.

Dernière modification par grim7reaper (Le 29/04/2010, à 12:21)

oracle_bot · Le 29/04/2010, à 13:09

Scores totaux, depuis le début:

1) 140    samuncle
2) 92    nesthib
3) 87    Pylade
4) 77    grim7reaper
5) 54    helly
6) 52    cm-t
7) 46    ǤƦƯƝƬ
8) 42    mathieuI
9) 37    ilagas
10) 19    Ouranos999
11) 17    tshirtman
11) 17    gnuuat
13) 15    Le Rouge
14) 12    stratoboy
15) 10    CROWD
16) 9    pierguiard
16) 9    kouskous
18) 7    Lagierl
19) 6    sailing
20) 5    oracle_bot
21) 4    Ph3nix_
21) 4    danychou56
21) 4    Neros
24) 3    Р'tite G☢gole :mad:
24) 3    Mornagest
26) 2    Kanor
27) 1    ceric
27) 1    pfriedK
27) 1    geenux

WCFCF XELEX ZYGDE VEMSQ SKXTZ VMGYX ELENL FCENG CTCES GPWHY G

oracle_bot · Le 29/04/2010, à 13:09

scores de la période en cours:

1) 130    samuncle
2) 85    nesthib
3) 81    Pylade
4) 67    grim7reaper
5) 54    helly
6) 52    cm-t
7) 39    ǤƦƯƝƬ
8) 37    ilagas
9) 35    mathieuI
10) 19    Ouranos999
11) 15    tshirtman
11) 15    Le Rouge
13) 12    stratoboy
13) 12    gnuuat
15) 10    CROWD
16) 9    pierguiard
16) 9    kouskous
18) 7    Lagierl
19) 6    sailing
20) 5    oracle_bot
21) 4    Ph3nix_
21) 4    danychou56
21) 4    Neros
24) 3    Р'tite G☢gole :mad:
24) 3    Mornagest
26) 2    Kanor
27) 1    ceric
27) 1    pfriedK
27) 1    geenux

WCFCF XELEX ZYGDE VEMSQ SKXTZ VMGYX ELENL FCENG CTCES GPWHY G

Pylades · Le 29/04/2010, à 15:27

Deux nouvelles fonctions créées, fonction principale atropt de plus que 87 lignes, futurs découpages à suivre, moyen de supprimer un return repéré.

Au fait : on parle de -fPIC et -fpic, sachant que la la dernière produit un code plus court, mais que ça ne marche pas sur toutes les architectures. Mais ça ne coûte rien de la mettre dans le Makefile, au moins celui que je vais utiliser pour produire les paquets (avec Linux/x86 ça marche) ?

Sinon, il est conseillé de ne pas stripper ses bibliothèques dynamiques pour des raisons de debug, mais pour une release, on peut le faire, non ?

Voilà.

Dernière modification par Pylade (Le 29/04/2010, à 15:52)

grim7reaper · Le 29/04/2010, à 15:45

Good, c'est cool ça. C'est toujours un peu difficile de s'y forcer au début mais c'est un truc que l'on regrette rarement.

Le code doit être beaucoup plus lisible maintenant, non ?

Pylades · Le 29/04/2010, à 15:53

Ouais, pas mal plus lisible, en effet.

Arf, tu as posté pendant que j’éditais…

grim7reaper · Le 29/04/2010, à 16:05

Si tu vises la portabilité met fPIC c'est plus sûr (le fonctionnement de fpic dépend du dynamic loader du système). Quitte à indiquer par un commentaire la possibilité d'optimisation dans le Makefile, ainsi on choisi de l'activer ou pas (mais par défaut mieux vaut être portable). Surtout que la taille des bibliothèques et exécutables est rarement critique.
Au fait il y a une grosse différence entre les deux ou pas ?

Sinon pour "stripped or not stripped" tu peux le faire mais ça ne semble pas être le choix le plus courant (dans mon /usr/lib j'ai 450 bibliothèques not stripped contre 72 stripped).

Dernière modification par grim7reaper (Le 29/04/2010, à 16:06)

Pylades · Le 29/04/2010, à 16:35

Bon, j’ai lu le man de GCC, et en fait si -fpic ne peut pas fonctionner sur le système, -fPIC est utilisé à la place. Donc pas de raison de s’en priver.

man gcc a écrit :

If the GOT (global offset table) size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead.

Bon, puisque ça se fait de stripper ses bibliothèques dynamiques, je vais le faire : je passe de 12,2 Kio à 10 Kio, c’est non négligeable (bon, OK, ça l’est un peu).

grim7reaper · Le 29/04/2010, à 16:38

Hum tu est sûr que gcc le fait de lui même, ou c'est le man qui te dit de recompiler toi même avec fPIC ?
La phrase me semble ambiguë, mais il me semble comprendre le contraire.

Sinon, tu ne serais pas un peu maniaque niveau taille ?

Pylades · Le 29/04/2010, à 16:49

Ah ouais, c’est vrai que vu comme ça… En effet, crois que tu as raison en fait.

Bon…

Et non, je ne suis pas maniaque niveau taille. J’ai juste un peu moins de 17 Gio à ma disposition, dont une bonne partie est occupée.

Sinon, que penses-tu de mon Makefile ?

CC=gcc
AR=ar
MAIN_CFLAGS=-std=c89 -pedantic -Wall -Wextra -Wstrict-prototypes -Wwrite-strings -Wunreachable-code
DEBUG_CFLAGS=-g -O0
RELEASE_CFLAGS=-O2
MAIN_LDFLAGS=-shared -Wl,-soname,libopt.so.0
DEBUG_LDFLAGS=
RELEASE_LDFLAGS=-s
LIB=libopt.a libopt.so.0.1-a1

ifeq ($(DEBUG),true)
CFLAGS=$(DEBUG_CFLAGS) $(MAIN_CFLAGS)
LDFLAGS=$(DEBUG_LDFLAGS) $(MAIN_LDFLAGS)
else
CFLAGS=$(RELEASE_CFLAGS) $(MAIN_CFLAGS)
LDFLAGS=$(RELEASE_LDFLAGS) $(MAIN_LDFLAGS)
endif


all: $(LIB)

libopt.a: atropt.o user.o
	$(AR) rcs $@ $^

libopt.so.0.1-a1: atropt.pic.o user.pic.o
	$(CC) $(LDFLAGS) $^ -o $@

atropt.o: atropt.c atropt.h
	$(CC) $(CFLAGS) $< -c -o $@

atropt.pic.o: atropt.c atropt.h
	$(CC) $(CFLAGS) -fpic $< -c -o $@

atropt.h: user.h

user.o: user.c user.h
	$(CC) $(CFLAGS) $< -c -o $@

user.pic.o: user.c user.h
	$(CC) $(CFLAGS) -fpic $< -c -o $@

.PHONY: clean mrproper

clean:
	@rm -f *.o

mrproper: clean
	@rm -f $(LIB)

Et il va falloir que je fasse un unique header en vue d’une release, non ? Là, j’en ai deux.

Dernière modification par Pylade (Le 29/04/2010, à 18:25)

grim7reaper · Le 29/04/2010, à 16:58

C'est un bon makefile. Bon, il y a moyen d'optimiser en utilisant les wildcards, variables internes et autres règles d'inférences, mais c'est bien comme ça (à la limite j'ajouterais la cible .PHONY pour clean et mrproper, histoire d'éviter de potentiels ennuis).

Ce n'est pas grave d'avoir 2 headers, mais pourquoi tu en a 2 maintenant ?

Pylades · Le 29/04/2010, à 17:08

grim7reaper a écrit :

Ce n'est pas grave d'avoir 2 headers, mais pourquoi tu en a 2 maintenant ?

Bah je fais un header pour chaque fichier source, mais je suis en train de me dire que quand on utilise une bibliothèque, on n’inclut pas 36 headers.

Pour .PHONY, bof, je n’aime pas trop utiliser des trucs qui sont là pour pallier à une éventuelle connerie. À moins de par la suite utiliser un script pour faire clean et mrproper, si ça devient trop compliqué, là ça ne me refroidirait pas de mettre un .PHONY.

grim7reaper · Le 29/04/2010, à 17:21

Bah 2 headers ça reste gérable, mais au pire fait un header global qui inclus les 2 autres.

Sinon qu'est ce qui te dérange avec .PHONY O_o" ??
Ton idée de faire un script à côté fais 42 fois plus : crade, bidouille, mec qui comprend rien à make et tout ce que tu veux de négatif .

Nan mais c'est crade quand même d'utiliser un script pour faire ce que fait déjà make. Tu t'amuses à faire un script pour lier tes fichier objet au lieu de passer par gcc ? Parce que là c'est un peu dans le même ordre d'idée.

C'est utilisé dans tout les Makefile que j'ai vu, c'est pas pour pallier une connerie c'est au cas où un gars appelle un de ses fichiers clean ou mrproper (si le gars connais rien au Makefile, il peut très bien faire un fichier de ce nom).

Pylades · Le 29/04/2010, à 17:37

grim7reaper a écrit :

Bah 2 headers ça reste gérable, mais au pire fait un header global qui inclus les 2 autres.

OK…

grim7reaper a écrit :

Sinon qu'est ce qui te dérange avec .PHONY O_o" ??
Ton idée de faire un script à côté fais 42 fois plus : crade, bidouille, mec qui comprend rien à make et tout ce que tu veux de négatif .
Nan mais c'est crade quand même d'utiliser un script pour faire ce que fait déjà make. Tu t'amuses à faire un script pour lier tes fichier objet au lieu de passer par gcc ? Parce que là c'est un peu dans le même ordre d'idée.

Ben oui, c’est très moche, mais je voulais dire que si on n’était obligé en arriver là (faire un script clean, appelé par make, bien sûr), à cause d’un projet collosal et très complexe, utiliser .PHONY ne me poserait pas de problèmes. Mais sans vraie raison, je fais un petit blocage psychologique (je sais, c’est mal).

grim7reaper a écrit :

C'est utilisé dans tout les Makefile que j'ai vu, c'est pas pour pallier une connerie c'est au cas où un gars appelle un de ses fichiers clean ou mrproper (si le gars connais rien au Makefile, il peut très bien faire un fichier de ce nom).

Ben ouais, c’est bien pour pallier à une éventuelle connerie qui a toutes les chances de ne jamais se produire si on sait ce que l’on fait, et de toute façons, si connerie et problème il y a, ce n’est absolument pas critique, et en une ligne dans le Makefile on a oublié.

Apparemment je ne me suis pas exprimé clairement. Mais rassure-toi, j’essaie de ne pas trop faire les choses comme un gros cochon.

compte supprimé · Le 29/04/2010, à 17:49

helly a écrit :

OUARRRRRRKKKK GNIGNIGNIGNIIIIIII !!!!!! ELLE MARCHE MON ÉNIGMA !!! HOURRAAAAAAAAAA!!
Je peux mourrir en paix maintenant

Tiens, je vais essayer d'en faire une en Python, ça me changera du ROT13

grim7reaper · Le 29/04/2010, à 17:50

Pylade a écrit :

Ben oui, c’est très moche, mais je voulais dire que si on n’était obligé en arriver là (faire un script clean, appelé par make, bien sûr), à cause d’un projet collosal et très complexe, utiliser .PHONY ne me poserait pas de problèmes. Mais sans vraie raison, je fais un petit blocage psychologique (je sais, c’est mal).

Quel intérêt de faire un script shell alors que le Makefile peut contenir des commandes et exécuter shell ?

Ben ouais, c’est bien pour pallier à une éventuelle connerie qui a toutes les chances de ne jamais se produire si on sait ce que l’on fait, et de toute façons, si connerie et problème il y a, ce n’est absolument pas critique, et en une ligne dans le Makefile on a oublié.

Non, ça n'a rien a voir avec le fait que tu saches ce que tu fais, la personne qui compile ton programme peut très bien ne pas être développeur ou ne rien connaître au Makefile et choisir ce nom par inadvertance (combien de gens compile des programmes en les appelant test, alors que c'est le nom d'une commande shell).

Et ce n'est pas critique pour clean ou mrproper mais ça pourrait l'être pour une autre règles sans dépendances.

Apparemment je ne me suis pas exprimé clairement. Mais rassure-toi, j’essaie de ne pas trop faire les choses comme un gros cochon.

Oui c'était pas très clair, d'où mon envolée lyrique .

Pylades · Le 29/04/2010, à 18:10

grim7reaper a écrit :

Quel intérêt de faire un script shell alors que le Makefile peut contenir des commandes et exécuter shell ?

Un script prend des arguments, et ça peut être plus flexible.

grim7reaper a écrit :

Non, ça n'a rien a voir avec le fait que tu saches ce que tu fais, la personne qui compile ton programme peut très bien ne pas être développeur ou ne rien connaître au Makefile et choisir ce nom par inadvertance (combien de gens compile des programmes en les appelant test, alors que c'est le nom d'une commande shell).
Et ce n'est pas critique pour clean ou mrproper mais ça pourrait l'être pour une autre règles sans dépendances.

Bon, t’as gagné, je vais l’ajouter.

grim7reaper a écrit :

Oui c'était pas très clair, d'où mon envolée lyrique .

grim7reaper · Le 29/04/2010, à 18:14

Pylade a écrit :

grim7reaper a écrit :
Quel intérêt de faire un script shell alors que le Makefile peut contenir des commandes et exécuter shell ?
Un script prend des arguments, et ça peut être plus flexible.

C'est vrai, un point pour toi .
Bon après quand make commence à montrer ses limites, on peut peut être trouver le salut dans CMake, Scons & cie (je pense, je n'ai jamais utilisé et il faudra que j'y jette un œil un jour).

Et ce n'est pas critique pour clean ou mrproper mais ça pourrait l'être pour une autre règles sans dépendances.
Bon, t’as gagné, je vais l’ajouter.

Dernière modification par grim7reaper (Le 29/04/2010, à 18:42)

Pylades · Le 29/04/2010, à 18:28

grim7reaper a écrit :

Pylade a écrit :
Bon, t’as gagné, je vais l’ajouter.

Du coup, j’ai édité le message où j’ai mis mon makefile.

Mais, euh… tu as eu des problèmes avec [quote] ?

grim7reaper · Le 29/04/2010, à 18:40

Où ça ? (C'est bon je l'ai vu )
(C'est probable, vu que je poste entre les erreurs 500 et 504 sans forcément me relire )

Dernière modification par grim7reaper (Le 29/04/2010, à 18:51)

Pylades · Le 29/04/2010, à 19:13

/me va-t-il continuer à bosser sa lib ?
Ou va-t-il bosser pour de vrai ?

Vous le saurez ce soir…
Surtout, ne manquez pas la nuit endiablée du Topic des Codeurs Couche-Tard.

grim7reaper · Le 29/04/2010, à 19:17

/me va sûrement bosser pour de vrai ce soir car /me doit se forcer à finir son algo d'Eller (ça fait une semaine que je le laisse trainer, et selon un planning optimiste ça devais être terminé depuis 2 semaines ) pour enfin passer à la résolution (qui risque de demander plus de boulot, ça tombe bien car il me reste justement moins de temps...).

Dernière modification par grim7reaper (Le 29/04/2010, à 19:17)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#826 Le 29/04/2010, à 11:56

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#827 Le 29/04/2010, à 12:07

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#828 Le 29/04/2010, à 12:12

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#829 Le 29/04/2010, à 12:18

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#830 Le 29/04/2010, à 13:09

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#831 Le 29/04/2010, à 13:09

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#832 Le 29/04/2010, à 15:27

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#833 Le 29/04/2010, à 15:45

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#834 Le 29/04/2010, à 15:53

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#835 Le 29/04/2010, à 16:05

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#836 Le 29/04/2010, à 16:35

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#837 Le 29/04/2010, à 16:38

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#838 Le 29/04/2010, à 16:49

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#839 Le 29/04/2010, à 16:58

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#840 Le 29/04/2010, à 17:08

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#841 Le 29/04/2010, à 17:21

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#842 Le 29/04/2010, à 17:37

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#843 Le 29/04/2010, à 17:49

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#844 Le 29/04/2010, à 17:50

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#845 Le 29/04/2010, à 18:10

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#846 Le 29/04/2010, à 18:14

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#847 Le 29/04/2010, à 18:28

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#848 Le 29/04/2010, à 18:40

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#849 Le 29/04/2010, à 19:13

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

#850 Le 29/04/2010, à 19:17

Re : ..:: Topic des Codeurs Couche-Tard [0] ::..

Pied de page des forums