Discussion :

[FoX_*D i E*]

Bonjour,

D'abord, j'ai du mal à comprendre pourquoi il y a beaucoup de sujet à propos des dll sous Windows mais aucun à propos des .so ....

J'ai fini un programme que j'ai développé sous Windows et Linux.

En mettant dans le dossier les DLL : mingwm10.dll, QtGui4.dll , et QtCore4.dll j'arrive à faire marcher mon programme sur un Windows sans Qt4

En mettant dans le dossier les so : libQtGui4.so.4 et libQtCore.so.4 je n''arrive pas à faire marcher mon programme sur un Linux sans Qt4
le message ressemble à :

error while loading shared library : libQtGui4.so.4 : cannot open shared object file : No such file or directory

help !

[kinji1]

Windows recherche les bibliothèques dans le dossier courant et dans les répertoires systèmes, alors que linux ne recherche que dans les dossier système.
Si tu veux qu'il cherche d'abord dans d'autres répertoires il faut par exemple les spécifier dans la variable d'environnement LD_LIBRARY_PATH. Mais bon demander ça à tous les utilisateurs de ton appli c'est un peu embêtant.

Donc le plus simple à mon avis c'est soit de supposer qu'ils ont (ou leur dire qu'ils doivent) installer la lib Qt 4 (ce qui est globalement la philosophie sous linux), soit mettre toi même les lib dans les répertoires systèmes (mais il faut faire attention à ne pas causer de futurs problèmes s'ils installent Qt par la suite).

[yan]

Salut.
Il me semble que l'on peut spécifier à l'appli où chercher les .so, mais je ne sais plus comment...
Ou alors ce n'est que pour mac.

[buggen25]

bonjour
essaye ça :

void QCoreApplication::addLibraryPath ( const QString & path )

j'espère je raconte pas de betises!!!!

voir aussi ce lien :
http://qt.developpez.com/doc/latest/...plication.html

[yan]

Ca c'est pour les plugin c'est un autre problème

[buggen25]

bonjour,

et pour ce thread ça peut marcher
http://qt.developpez.com/doc/latest/...tml#QLibrary-2

[kinji1]

Sauf que lui c'est les libs de Qt qu'il veut charger, donc il va avoir du mal a utiliser cette fonction pour qu'elles s'auto-chargent.

[buggen25]

Je suis d'accord

J'ai trouvé ce lien sur developpez.com
http://hiko-seijuro.developpez.com/a...que-dynamique/

C'est dans le coup ou pas du tout

[yan]

J
C'est dans le coup ou pas du tout

non

En faite tout dépend comment la dll est utilisé. Si elle est linké avec l'appli, c'est le système (en gros) qui charge la dll pour pouvoir lancer l'application. Ce qui correspond à son problème. Tu ne peut donc rien faire avec le code. Juste au link ou en jouant avec l'environnement (comme les path système).

Ou alors c'est ton appli qui charge la dll pour l'exploiter et la tes lien corresponde

[FoX_*D i E*]

resalut !

merci pour ces recheches, on voit que ce forum est actifs meme pour des sujets douteux, ce qui n'est pas le cas dans le forum "officiel" de Qt.

- vu comment c'est compliqué,
- vu que je n'ai pas envie d'obligé l'utilisateur d'installer Qt4
- vu que je n'ai pas envie de lui mettre des .so qui pourrait faire planter une future instal de Qt
- vu qu'à priori on ne peut rien mettre dans le code de mon appli


je vois deux probables solutions, SVP dites moi si ca tient le coup et laquelle est la plus propre :

1- faire un .sh (un.bat chez windows) qui change le path pour ajouter le dossier courant, puis qui lance l'appli
Je mettrais alors dans le readme qu'il faut lancer le .sh et pas directement l'appli

2-compiler l'appli en static pour integrer ses .so dans l'appli, ainsi elle sera indépendante (je crois qu'on en a déjà parlé Mongaulois)
mais dans ce cas la, puisque j'utilise le linux de mon entreprise et que j'ai pas envie de lui faire peter le Qt, ya-t-il un moyen de rajouter dans le makefile une option pour qu'il compile SEULEMENT ce projet en static, et que tout autre compile reste en dynamique

advice !

[FoX_*D i E*]

1- faire un .sh (un.bat chez windows) qui change le path pour ajouter le dossier courant, puis qui lance l'appli
Je mettrais alors dans le readme qu'il faut lancer le .sh et pas directement l'appli

ok déjà ca ca ne semble pas fonctionner

un export PATH=$PWD:$PATH
ne change rien à l'affaire

[yan]

merci pour ces recheches, on voit que ce forum est actifs meme pour des sujets douteux, ce qui n'est pas le cas dans le forum "officiel" de Qt.

quel forum officiel?

1- faire un .sh (un.bat chez windows) qui change le path pour ajouter le dossier courant, puis qui lance l'appli
Je mettrais alors dans le readme qu'il faut lancer le .sh et pas directement l'appli

c'est la plus simple à mon avis

2-compiler l'appli en static pour integrer ses .so dans l'appli, ainsi elle sera indépendante (je crois qu'on en a déjà parlé Mongaulois)
mais dans ce cas la, puisque j'utilise le linux de mon entreprise et que j'ai pas envie de lui faire peter le Qt, ya-t-il un moyen de rajouter dans le makefile une option pour qu'il compile SEULEMENT ce projet en static, et que tout autre compile reste en dynamique

Il faut compiler Qt en static pour cela. Attention ca complique l'utilisation des plug in.

[FoX_*D i E*]

"quel forum officiel?"

j'sais plus, j'avais l'impression d'être déjà tombé sur un forum officiel
plus de preuves !!!

ok déjà ca ca ne semble pas fonctionner

un export PATH=$PWD:$PATH
ne change rien à l'affaire

ouahhh magique,
ca marche avec LD_LIBRARY_PATH alors que cette variable n'existait pas avant que je la définisse

merci kinji1 !

problème résolu :

écrire un 'MyProgram.sh' qui devra etre exexuté à la place de 'MyProgram'

à l'interieur :

export LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH
MyProgram

voila tout.(mais pourquoi donc linux ne prend pas en plus le repertoire courant comme path pour les lib, ca complique pour rien)

[yan]

mais pourquoi donc linux ne prend pas en plus le repertoire courant comme path pour les lib, ca complique pour rien

Linux, windows et mac gère cela à leur sauce. Après pourquoi, y as surement une bonne raison
Si tu va sur le forum linux, t'auras surement une réponse

[yan]

http://www.linux.com/base/ldp/howto/...libraries.html

[kinji1]

Si tu veux faire sioux, tu compiles ton application sous le nom appli-bin et tu appelles ton script appli (sans extension). Comme ça les utilisateurs verront même pas (pour la plupart) qu'il y a un script.