Discussion :

[uriotcea]

Bonjour,

J'ai developé un code avec la lib pthread sous windows et gcc 4.4.0
J'ai inclu au link les libraries libpthread.a & libpthreadGC2-static.a & libpthreadGCE2.a et malgré cela si je vais sur une machine sans installation de gcc ou posx j'obtient qu'il me manque une dll : pthreadGC2.dll

Je ne comprend pas bien pourquoi. Si quelqu'un a déjà eu ce probléme

Merci d'avance

[Flow_75]

Bonjour,

J'ai developé un code avec la lib pthread sous windows et gcc 4.4.0
J'ai inclu au link les libraries libpthread.a & libpthreadGC2-static.a & libpthreadGCE2.a et malgré cela si je vais sur une machine sans installation de gcc ou posx j'obtient qu'il me manque une dll : pthreadGC2.dll

Je ne comprend pas bien pourquoi. Si quelqu'un a déjà eu ce probléme

Merci d'avance

Je ne comprend pas...
Tu dis que quand tu mets ton executable sur une autre machine, il te dit qu'il te manque 'pthreadGC2.dll' ?

Mais c'est normal. aucun rapport avec gcc ou posx.
Dans le package que tu as du telecharger pour compiler sous windows il y a les dll adéquats.

[uriotcea]

Oui biensur mais ayant linké en static les avec *.a pourquoi faut-ils encore une dll, a quoi servent donc les *.a ?

[Flow_75]

Oui biensur mais ayant linké en static les avec *.a pourquoi faut-ils encore une dll, a quoi servent donc les *.a ?

Le *.a fait le lien entre ton programme et la Dll.

[uriotcea]

Là je ne pense pas!
Ce sont réellement des librairies, pour preuve elles font pratiquement la même taille que les dll correspondantes.
De plus je fais ca tout le temps par exemple avec Qt je link en static avec les *.a evitant ainsi d'avoir à distribuer les dll

[Mac LAK]

Là je ne pense pas!
Ce sont réellement des librairies, pour preuve elles font pratiquement la même taille que les dll correspondantes.

Les deux autres librairies ne possèdent pas la mention "static" dans leur nom, il est donc possible qu'elles lient dynamiquement la troisième.

De plus je fais ca tout le temps par exemple avec Qt je link en static avec les *.a evitant ainsi d'avoir à distribuer les dll

Ce qui, en soi, est quand même plutôt crado, voire irrespectueux de l'utilisateur final... Des dizaines et des dizaines de mégas de dur plombés pour chaque petit outil existant, sans compter la RAM qui s'épuise à force de ne PAS avoir de partage des librairies (ben oui, une statique en dix exemplaires dans la RAM, c'est dix fois la taille...), c'est pas franchement une bonne démarche je trouve. Pour moi, afin de t'éviter dix minutes de packaging et de tests de dépendances, tu plombes les machines des utilisateurs, c'est là qu'est l'irrespect.

Si vraiment tu veux réduire les soucis de l'utilisateur, tu distribues l'exécutable et ses DLL, et tu rends l'installation des DLL optionnelles dans ton setup (ou, mieux, tu ne les installe que si tu ne les trouve pas). Si tu veux économiser de la bande passante, ou avoir des setups plus petits, tu distribue les DLL à part, téléchargés à la demande.


Tu fais comme tu le sens bien sûr, mais me retrouver avec un exécutable de 10 mégas qui me plombe le double en RAM, va vraiment falloir que l'appli soit intéressante... Si c'est un gadget, c'est poubelle direct.

[uriotcea]

Les deux autres librairies ne possèdent pas la mention "static" dans leur nom, il est donc possible qu'elles lient dynamiquement la troisième..

Si justement son nom est "libpthreadGC2-static.a". C'est pourquoi je ne comprend pas bien l'utilité de la dll.

Concernant la taille des executables. C'est une question de phylosophie. Pour ma part je link maintenant tout en static, même sous linux ou j'en ai vraiment mare de toutes ces dépendances complexes qui font que mes codes ne fonctionnent que sur certains systemes et pas d'autre sur certaines versions de gcc par example et pas d'autre sans parler des libgcc, libstdcc++ qui ne sont jamais compatible d'une version à l'autre. Depuis que je link tout en static, plus de soucie. Ok, la taille est plus grosse, mais franchement que sont quelques MOctects de nos jour...

[Mac LAK]

Si justement son nom est "libpthreadGC2-static.a". C'est pourquoi je ne comprend pas bien l'utilité de la dll.

Sauf que tu linkes "libpthread.a" (et non pas une éventuelle "libpthread-static.a"), ainsi que "libpthreadGCE2.a" (au lieu d'une "libpthreadGCE2-static.a")... Je ne connais pas la tripaille interne de ces deux librairies, mais il est fort possible que les versions que tu linkes utilise la version dynamique de "libpthreadGC2"...

Concernant la taille des executables. C'est une question de phylosophie. Pour ma part je link maintenant tout en static, même sous linux ou j'en ai vraiment mare de toutes ces dépendances complexes qui font que mes codes ne fonctionnent que sur certains systemes et pas d'autre sur certaines versions de gcc par example et pas d'autre sans parler des libgcc, libstdcc++ qui ne sont jamais compatible d'une version à l'autre. Depuis que je link tout en static, plus de soucie.

C'est pour ça que l'on fait du packaging : on distribue les runtimes en même temps que le programme, et on distribue les librairies en parallèle ou packagées avec l'application, de préférence via le package de l'éditeur afin d'assurer une installation la plus propre possible... Sous Windows, tu as bien sûr InnoSetup qui t'aidera à faire ça. Sous Linux, je pense qu'un bon RPM avec les dépendances correctes reste l'idéal.

Si tes programmes sont aussi "complexes" à rendre utilisables partout, tu as deux possibilités :

• Ils utilisent trop de librairies, qui ne sont pas forcément utilisées dans leur mode idéal.
  Si tu utilises une librairie pour une seule fonction, un link statique est avantageux. Si tu t'appuie massivement dessus, la DLL est plutôt de rigueur.
• Tu n'as pas les bons outils pour obtenir les dépendances de tes exécutables, ce qui rend la chose "aléatoire" au mieux, mais hélas pas rationnelle. Tu peux voir avec Dependancy Walker sous Windows, ou ldd sous Linux (il y a sûrement mieux que ldd toutefois...).

Ok, la taille est plus grosse, mais franchement que sont quelques MOctects de nos jour...

Ce que je t'ai expliqué un peu plus haut... La RAM, c'est pas encore le disque dur, ça se remplit bien plus vite. Quand je vois de petits programmes tout juste amusants bouffer 100 Mo de RAM à eux tout seuls à cause de liaisons 100% statiques, il y a de quoi trouver ça "abusé", surtout quand ils pourraient n'en consommer que 5 ou 10 en utilisant des DLL déjà chargées sur le système par d'autres applications...
Comme je te le disais, pour ma part, je mets ce genre de programme direct à la poubelle, quel que soit l'intérêt du programme en question.

Record personnel pour l'instant : une application de post-it sur le bureau Windows, dont j'ai oublié le nom hélas, et qui consommait plus de 600 Mo de RAM à elle toute seule...

[uriotcea]

Ok, je suis sensible à tes arguments, mais en fait mon programme en l'occurence consomme quelquechose comme 1.5 Goctet

Malgré tout si je suis toujours à la recherche d'une méthode pour linker en static la lib pthread, si quelqu'un à une suggestion

[Mac LAK]

Ok, je suis sensible à tes arguments, mais en fait mon programme en l'occurence consomme quelquechose comme 1.5 Goctet

Et via un link dynamique, il occupe combien ? Bon, blague à part, c'est plutôt énorme, je suis assez surpris du volume... C'est à peu près ce que consomme World of Warcraft, tu sais ?

Malgré tout si je suis toujours à la recherche d'une méthode pour linker en static la lib pthread, si quelqu'un à une suggestion

Tu n'as aucune autre librairie ".a" disponible, dans le répertoire lib ? Pas de version statique des librairies de base ? Pas de librairies tierces (genre QT) qui linkeraient par défaut la version dynamique ?

Si tu n'as aucune autre librairie explicitement définie comme statique à linker, il faudrait peut-être aller voir du côté des dépendances binaires...

Essaie de faire un "ldd -v", ou un Dependancy Walker, sur ton programme afin de voir si tu as une dépendance secondaire vers cette DLL...

[uriotcea]

Dependancy Walker trouve une dependance directe à cette fameuse dll pthreadGC2
Je crois qu'il faut recompiler la lib pthread en static, mais là galére visiblement MinGW ne semble pas suffire, il faudrait quelque chose appelé PERL. J'avoue ignorer ce que c'est au just

[Mac LAK]

Dependancy Walker trouve une dependance directe à cette fameuse dll pthreadGC2

Bon, c'est déjà une bonne nouvelle, tu n'es donc pas fou !! Si la dépendance est directe, c'est soit qu'elle est faite dans TON code/link (j'ai des doutes, d'après tes messages précédents), soit dans des librairies statiques linkées (beaucoup plus probable).

Je crois qu'il faut recompiler la lib pthread en static, mais là galére visiblement MinGW ne semble pas suffire, il faudrait quelque chose appelé PERL. J'avoue ignorer ce que c'est au just

Perl est un langage, tu peux trouver un interpréteur sous Windows, et sans difficultés de déploiement, normalement... Au pire, si tu l'as déjà, sous Cygwin si celui "natif" Windows te pose des soucis, mais il n'y a pas de raisons.

[uriotcea]

Ok, j'ai installé un truc nomé "strawbrerry" qui est un perl pour windows et quand j'excute le make file spécifié dans la doc de pthread j'ai les massage suivant comme si perl n'était pas installé...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
 
D:\temp\pthreads>mingw32-make clean GC-static
rm -f *~
process_begin: CreateProcess(NULL, rm -f *~, ...) failed.
make (e=2): Le fichier spÚcifiÚ est introuvable.
mingw32-make: [clean] Error 2 (ignored)
rm -f *.i
process_begin: CreateProcess(NULL, rm -f *.i, ...) failed.
make (e=2): Le fichier spÚcifiÚ est introuvable.
mingw32-make: [clean] Error 2 (ignored)
rm -f *.o
process_begin: CreateProcess(NULL, rm -f *.o, ...) failed.
make (e=2): Le fichier spÚcifiÚ est introuvable.
mingw32-make: [clean] Error 2 (ignored)
rm -f *.obj
process_begin: CreateProcess(NULL, rm -f *.obj, ...) failed.
make (e=2): Le fichier spÚcifiÚ est introuvable.
mingw32-make: [clean] Error 2 (ignored)
rm -f *.exe
process_begin: CreateProcess(NULL, rm -f *.exe, ...) failed.
make (e=2): Le fichier spÚcifiÚ est introuvable.
mingw32-make: [clean] Error 2 (ignored)
rm -f pthread.def
process_begin: CreateProcess(NULL, rm -f pthread.def, ...) failed.
make (e=2): Le fichier spÚcifiÚ est introuvable.
mingw32-make: [clean] Error 2 (ignored)
mingw32-make XOPT="-DPTW32_BUILD_INLINED -DPTW32_STATIC_LIB" CLEANUP=-D__CLEANUP
_C XC_FLAGS=" " OBJ="pthread.o version.o" libpthreadGC2.stamp
mingw32-make[1]: Entering directory `D:/temp/pthreads'
rm -f libpthreadGC2.a
process_begin: CreateProcess(NULL, rm -f libpthreadGC2.a, ...) failed.
make (e=2): Le fichier spÚcifiÚ est introuvable.
mingw32-make[1]: *** [libpthreadGC2.stamp] Error 2
mingw32-make[1]: Leaving directory `D:/temp/pthreads'
mingw32-make: *** [GC-static] Error 2

[uriotcea]

Ok j'ai enfin réussi
En fait Perl ne sert à rien, just ajouter rm.exe dans les executables de MINGW, je supose que c'est l'interpreteur de commandes.
Ensuite recompiler la lib pthread en static, avec 'mingw32 clean GC-static'
Ensuite ajouter cette lib aux liens suivit de 'libws2_32.a' (dans cet ordre là)
Ajouter l'option "PTW32_STATIC_LIB" dans les includes
Et pour finir ne pas oublier d'appeler la fonction
'pthread_win32_process_attach_np()' avant le premier appel d'une routine pthread
Et là tout marche correctement dans dll

Merci pour votre aide

[Mac LAK]

just ajouter rm.exe dans les executables de MINGW, je supose que c'est l'interpreteur de commandes.

Non, c'est l'équivalent de "del" sous Unix.

Et là tout marche correctement dans dll

Merci pour votre aide

Content pour toi. Bonne continuation !

[uriotcea]

L'equivalent de del !!!
Oui tu as probablement raison, mais c'est trés étrange que ca ai bloqué sur ca. Parfois il y a des choses qui m'échappe totalement!!

Maintenant, j'ai posté un neauveau topic parce que mon calcul multitreaded me donne satisfaction sous windows, mais je n'obtient vraiment pas les performances attendues sous linux