quel est votre avis sur la question dans le cadre d'une utilisation sous linux

ben ouais , j'en vois déjà me parler de BeOS ou Windows...

les deux mon neveu (je veux dire au choix )
 
Sinon static. Ex. d'opera, QT c'est lourd et inutile sous Gnome/E...

[edtdd]--Message édité par 911GT3--[/edtdd]

j'ose même pas demander la différence

Piksou a écrit a écrit : j'ose même pas demander la différence

bah ouais c koi la diff

• programme avec libs dynamique : le programme va utiliser les fonctions de la lib en se servant de la lib installé sur ton système.  

les libs dynamiques sous linux (équivalent des DLL de windows = Dynamic Link Librairy ) sont les .so ( shared object )
 
pour voir les libs utilisés par un prog, il suffit de faire :
> ldd prog
 
par exemple pour la commande ls qui se trouve dans le rep /bin, cela donne :
[will@bastard will]$ ldd /bin/ls
 libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000)
 libc.so.6 => /lib/libc.so.6 (0x40031000)
 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

 

• prog avec des libs statiques : le programme lors de sa compilation va directement intégrer les fonctions dont il a besoin à l'intérieur de lui. il n'utilisera pas la lib installé sur votre système.

désolé je n'ai pas d'exemple sous la main.
 
Par exemple opera Opera utilise Qt pour gérer son interface graphique. Or il se peut que kelk'un n'install pas Qt ( car il n'utilise pas KDE, n'utilise aucun prog ayant besoin de Qt, etc ... ).
Avec la version dynamique, si tu n'as pas Qt il faudra que tu l'install sinon il ne marchera pas.
Avec la version statique que tu ais Qt ou non, il fonctionnera car il n'utilisera pas la lib installé sur ton système.
 

• Avantages/inconvénients :

un programme compilé en statique est plus gros car il contient les lui en lui. Si le prog utilise bcp de libs cela en fait autant a l'intérieur de l'exécutable et augmente d'autant la taille.
 
le programme compilé en dynamique est plus petit mais il est dépendant de ce qui est installé sur ton système.
Par exemple si tu n'as pas la lib, il ne marche pas. Ou si tu as la mauvaise version, il ne marchera pas non plus.

en reprenant l'exemple de Opera, Opera s'appuie sur les librairies QT pour générer/gérer ces fenêtres. Il existe une version static qui inclus dans l'executable (ou au moins dans le 'package') les librairies nécessaires (peut-être juste des bouts de code ?) et une version dynamique qui s'appui sur les librairies installées sur le système (dans /usr/lib et autres).
 
Dans le premier cas l'executable est plus gros que le deuxième mais "Opera static" est plus petit sur le disque que "Opera Dynamique + QT" et ne profitera pas d'éventuelles améliorations dans ces librairies (mais ne posera pas non plus de problèmes de version).
 
En gros et en vrac

Une fois de plus pris de vitesse par (une) DS
 
Je vais finir par le prendre mal

ah, c le bon vieux coup des DLL partagées dans system ou en propre ds le rep de chaque prog !
bah sous linux je me garderais bien de donner mon avis car je ne maitrise pas assez mais sous win (sorry chonk ) bah je suis pour les statiques vu le prix dérisoire des HD de nos jours et leur capacité: ça évite tant d'emmerdes ! ou alors uniquement des libs propre à un éditeur (genre entre office et IE) mais sous nux, la dernière partie semble difficilement transposable à cause des multitudes de projets sans lien les uns avec les autres.

thx dark et 911

Piksou> ce n'est surement pas comme sous win.
 
1°/ tous les .so sont dans les rep lib du sys ( /usr/lib /usr/local/lib /usr/X11R6/lib ).
 
2°/ si tu utilises un rpm/deb, si le prog veut écraser des fichiers/libs, il geulera.
 
3°/ normalement les sources en tar.gz sont censé foutre leur merdier dans /usr/local/lib et non des libs de base du sys (mais bon ca dépend du bon vouloir du gars qui fait le prog). Encore une raison qui fait ke je n'aime pas les tar.gz ou les utilisent avec ... parcimonie.
 
4°/ cela peut vraiment grossir très vite. Il n'y a pas de limite quand à la taille de l'exécutable cela bouffe autant de RAM ke la taille de l'exe)
 
5°/ mais il est vrai que pour les upgrade d'un sys c'est moins casse tête et cela permet d'utiliser certains vieux prog qui n'ont plus été mis à jours.
 

[root@bastard root]# ldd /usr/bin/konqueror
 konqueror.so => /usr/lib/konqueror.so (0x4002d000)
 libkonq.so.3 => /usr/lib/libkonq.so.3 (0x400c3000)
 libkparts.so.1 => /usr/lib/libkparts.so.1 (0x40153000)
 libkfile.so.3 => /usr/lib/libkfile.so.3 (0x40181000)
 libksycoca.so.3 => /usr/lib/libksycoca.so.3 (0x40219000)
 libkio.so.3 => /usr/lib/libkio.so.3 (0x402d9000)
 libkdesu.so.1 => /usr/lib/libkdesu.so.1 (0x40398000)
 libutil.so.1 => /lib/libutil.so.1 (0x403ba000)
 libkssl.so.2 => /usr/lib/libkssl.so.2 (0x403bd000)
 libkdeui.so.3 => /usr/lib/libkdeui.so.3 (0x403e4000)
 libkdecore.so.3 => /usr/lib/libkdecore.so.3 (0x405f9000)
 libdl.so.2 => /lib/libdl.so.2 (0x40791000)
 libDCOP.so.1 => /usr/lib/libDCOP.so.1 (0x40795000)
 libqt.so.2 => /usr/lib/libqt.so.2 (0x407cb000)
 libpng.so.2 => /usr/lib/libpng.so.2 (0x40cb8000)
 libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40cdf000)
 libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40d00000)
 libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40d0f000)
 libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40df9000)
 libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40e02000)
 libresolv.so.2 => /lib/libresolv.so.2 (0x40e1a000)
 libz.so.1 => /lib/libz.so.1 (0x40e2c000)
 libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40e3b000)
 libm.so.6 => /lib/libm.so.6 (0x40e83000)
 libc.so.6 => /lib/libc.so.6 (0x40ea6000)
 libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x40fe4000)
 libGL.so.1 => /usr/lib/libGL.so.1 (0x41007000)
 libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x41044000)
 libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x4105b000)
 libmng.so.1 => /usr/lib/libmng.so.1 (0x41088000)
 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
 libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x410cd000)
 libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x41471000)
 libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x414c4000)
 libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x414c9000)
 liblcms.so.1 => /usr/lib/liblcms.so.1 (0x41503000)

c't'usine à gaz ..........

opera pas mieux :  
 
 
nico - 19:52:36 netoid2 ~/bin/eccp/stats > ldd /usr/bin/opera
        libm.so.6 => /lib/libm.so.6 (0x40026000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40047000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x40069000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4008f000)
        libdl.so.2 => /lib/libdl.so.2 (0x400a6000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x400aa000)
        libqt.so.2 => /usr/lib/libqt.so.2 (0x400f2000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4060f000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x406fb000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4070a000)
        libc.so.6 => /lib/libc.so.6 (0x40721000)
        libz.so.1 => /lib/libz.so.1 (0x4084e000)
        libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x4085d000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0x4087f000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x408bc000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x408c5000)
        libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x408dd000)
        libmng.so.1 => /usr/lib/libmng.so.1 (0x40903000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40946000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40999000)
        libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40d3d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40d42000)
 
 
 
ca semble lourd de developper un GUI sous nux ...

mon avis est que c'est encore l'age prehistorique pour les dvlp d'interface graphique .....  
 
trop de libs , d'objets a la mord moi l'noeud ........ bcp trop lourd ...

nicotine> tiens tu as la version dynamique de Opera.
 
non pas vraiment.
 
libstdc++-libc6.2-2.so.3 et libc et consors, eux sont des linkages pour la glibc ( indispensable pour tout exécutable sous linux en dynamique ou statique).
 
libjpeg, libpng : pointent vers des libs extérieures spécialisés dans la gestion du PNG et jpeg. l'avantage est que tu n'as pas besoin de recoder un moteur qui va gérer ces formats et de maintenir ce moteur soit pour l'améliorer, soit pour suivres les nvelles versions de PNG/JPEG.
 
libXft, libfreetype : les fontes, gérées par XFree, notamment les true type, donc tu profite de l'accele matériel de XFree, plutot que de faire un truc en software ou de te faire chier a en faire un avec accel matériel. là ce sont les gars de XFree qui se démerdent. et on pourrait dire ke c'est leur boulot.
 
libGL : Qt peut utiliser OpenGL en natif, meme sous win les prog sont linké avec opengl32.dll
 
libX11 : pour utiliser X11. Tu ne vas pas nous refaire en même temps un nveau serveur graphique.
 
libXrender : c'est pour l'AA ( Anti Aliasing) et la gestion de l'alpha channel ( transparence ) sous XFree. Bien sûr tu peux faire tout cela toi même, mais ce sera en software et donc plus lent.
 
libXext : encore d'autres extensions de XFree.
 
l'intéret des libs ( dynamiques ou pas ) c'est ke cela te permet de déléguer certaines choses à des libs extérieures et de te pencher sur ton programme et ce que tu veux faire.
Sous windows on utilise bcp aussi les dll (install et désinstall des progs , tu verras tout ce qu'il utilise quand il dit que il ne sais pas si il veut l'enlever, etc ... ).

java a un gros inconvenient (les ressources) mais un gros avantage .

dvlp un GUI rapidos ? inconcevable ( sous nux et windoz d'ailleurs).
 
la seule lib *pratique*  d'approche est php-gtk .  le reste , faut s'investir 6 mois pour utiliser correctement un objet Gtk ... j'ai abandonné d'ailleurs .

Avec Tcl/Tk ça va plutôt vite.

nicotine> normale.
gtk c'est du C, donc l'OO avec gtk ...
il faut alors des libs pour l'interface.
je peux te dire qu'avec Qt et un RAD de type kdevelop ou qt designer ca va très vite.
et bien sur tu as des bindings python, etc ...
 
si tu veux plus d'info j'essaierai d'en trouver.

dès que t'as le temps , ouais , ca serait sympa ...

les bindings pour kde -> http://developer.kde.org/language-bindings/index.html
 
pour gnome -> http://erik.bagfors.nu/gnome/languages.html

oki thx

DS: merci pour le cours
j'ai donc eu raison de ne pas parler de ce que je ne connaissait pas

Ouais donc voilà vous etes tout a fait rentrés dans le débat auquel je pensais !
Moi perso, je trouve que on se fait vraiment trop chier aujourd'hui en utilisant des tas de librairies dynamiques dans tous les sens, si bien que dès lors qu'un veut installer une nouvelle appli, ben elle a besoin de telle lib PLUS récente et tu coup on veut l'updater et pis le systeme dit NON NON NON tu peux pas sale geek, parceque tel autre prog a besoin de cette lib avec CETTE version là et du coup, une fois sur 1 on est fucked up...
franchement je trouve ça bien lourd
que les developpeurs intègrent les libs dont ils ont besoin dans leurs progs et on s'en portera bien mieux... y a qu'a voir opera , ca marche très bien.
Bon ok , on allourdi le systeme mais bon... y a qu'a voir windows XP, ca prend 2,3 Go installé sans AUCUNE appli !!! ( ) et personne s'en plaint !!! alors que ma debian avec X, des applis, ca prend 350 Mo....
A méditer !

Martinez> et donc justifies l'attitude de MS.
on utilises toujours et toujours plus de RAM ( XP vaut mieux 256 désormais ) et de puissance proc et ce sous prétexte que la RAM coûte de moins en moins cher.
 
Maintenant on a tendance a développer comme des porcs et même dans les softs finaux on dirait qu'ils laissent les symboles de débugage.
 
Il faut que les gens gardent l'habitude de programmer proprement et efficace.
 
quand chaque appli en statique fera de 10 voire 100Mo rien que pour l'exécutable, je pense tu seras moins content. sans compter les éventuelles pbs d'adressage et de mapage de la RAM.

Vous oubliez un truc dans vos calcul
 
Dans la version dynamique la librairie sera charée une fois en mémoire et grace a la MMU elle sera virtuellment dupliquée N fois.
 
Si tu lances KDE, Kdevelop, KaKa , Qt sera chargé une seule fois
En version statique Qt serait chargé N fois

à bas ch'ui content, j'ai appris un truc (à vrai dire, j'm'étais jamais posé la question )

mean> tout a fait raison. c'est comme si le prog fonctionnait tout seul : aucune optimisation à ce niveau concernant la gestion de la RAM !
 
comme je disais c'est virtuellement la taille de l'exécutable sans espérer qu'il ira piocher en RAM plutôt que de recharger une lib.
 
Sous windows où le système est beacoup plus centralisé ( toutes les libs sont là ), soit ils utilisent les libs win, soit ils refont les libs, soit il mettent leur propre version des libs win.

Hummmm... mon avis sur la question :
 
Les libs dynamiques, il en faut :

• c bien, ca allège les elfs (mais bon, vu que quasiement personne ne strippe ses elfs, je suis pas sur que la taille d'un executable soit importante)
• pour une gestion globale des programmes installés, c très pratique... exemple : sdl... toutes les maj mineures de la SDL évitent d'avoir à recompiller mplayer, tuxracer, et touti quanti...
• Ca épargne énormément la charge système... car le gestionnaire de mémoire Linux partage la même zone mémoire entre tous les programmes qui utilisent la même lib -> elle n'est chargée qu'une fois, ce qui évite la lourdeur de certaines grosses libs (genre ssl, ...)

Maintenant, les inconveignants :

• les libs mal concues/penssées n'ont aucune compatibilité ascendente, ce qui force à avoir plusieurs versions d'une lib sur son dur, ce qui deviens rapidement lourd voir impossible à gérer si elles ont le même nom (même si elles sont dans des reps différents du LDPATH, le ld.cache ne peux pour le moment contenir qu'une version d'une lib dans certains cas...)
• c une atrocitée d'un point de vue securitée... Il suffit de modifier une fonction 'une lib pour corrompre l'enssemble des binaires... Je peux vous donner des exemples si ca vous interesse...
• les appels de fonctions ne sont pas dans le même process, il faut donc swapper de process pour un appel de fonction parfois tout con (la gestion d'erreur de certaines libs est parfois plus merdiques qu'un perror )

... voila pour simplifier le tout...
donc, en gros :

• les grosses libs imposantes, les trucs pas vitaux, et les libs génériques (très utilisées) -> dynamique...
• les libs de secu/fonctions système/haute dispo sans fork/threads -> statique

je ne suis pas programmeur, j'ai déjà du mal à utiliser linux mais je me disais que ce serait bien de répertorier les programmes spécialement bien pensés et ceux au contraire qui sont des usines à gaz mais parfois très répandus car disposant de telle ou telle fonctionnalité.
 
Je lisais plus haut que Windows XP prenait plus de deux Go (en fait il en prend 800mo) c'est énorme et ridicule sachant que c'est avant tout un OS qui est vendu  avec des PC grand public avec la (sous) utilisation que ça induit.  
 
En ce sens, j'aime énormément Linux (ça me rappelle tellement l'Amiga OS) mais je suis quand même un peu déçu de la lourdeur des applications en général. J'ai tout sauf envie d'utiliser Gnome et KDE, idem pour Mozilla, et plein d'autres encore...
 
Bref, je suis à la recherche de perles optimisées, programmées proprement quitte à perdre en fonctionalité. C'est la quête sans fin du Graal.

 
Pourquoi tu fait pas un topic dédié, ce serais plus à sa place ?