Non, un programme sérieux n'aurait pas ce genre de grotesquitude. Mais wengo m'a tout l'air d'être particulièrement simiesque.
L'executable devrait être qtwengophone. Visiblement j'ai du foiré l'installation. Malgrès tout ça marche.
-- @+ gr
Doug713705
Le dimanche 11 février 2007 19:48, G-raison s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Par contre je trouve drôle de devoir taper LD_LIBRARY_PATH=. ./qtwengophone pour démarrer wengo. Est-ce normal?
C'est très moche. Cela veut dire que les librairies nécéssaires au fonctionnement de wengo sont installées dans le repertoire d'installation de wengo et non pas avec les autres librairies (généralement installées dans /usr/lib et consort).
On se croirait sous Windows !
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne): - rajouter au fichier /etc/ld.so.conf : /repertoire/installation/wengo
-- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
Le dimanche 11 février 2007 19:48, G-raison s'est exprimé de la sorte sur
fr.comp.os.linux.configuration :
Par contre je trouve drôle de devoir taper LD_LIBRARY_PATH=.
./qtwengophone pour démarrer wengo.
Est-ce normal?
C'est très moche.
Cela veut dire que les librairies nécéssaires au fonctionnement de wengo
sont installées dans le repertoire d'installation de wengo et non pas avec
les autres librairies (généralement installées dans /usr/lib et consort).
On se croirait sous Windows !
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne):
- rajouter au fichier /etc/ld.so.conf :
/repertoire/installation/wengo
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Le dimanche 11 février 2007 19:48, G-raison s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Par contre je trouve drôle de devoir taper LD_LIBRARY_PATH=. ./qtwengophone pour démarrer wengo. Est-ce normal?
C'est très moche. Cela veut dire que les librairies nécéssaires au fonctionnement de wengo sont installées dans le repertoire d'installation de wengo et non pas avec les autres librairies (généralement installées dans /usr/lib et consort).
On se croirait sous Windows !
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne): - rajouter au fichier /etc/ld.so.conf : /repertoire/installation/wengo
-- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
lhabert
Doug713705 :
C'est très moche.
Pas tant que ça.
Cela veut dire que les librairies nécéssaires au fonctionnement de wengo sont installées dans le repertoire d'installation de wengo et non pas avec les autres librairies (généralement installées dans /usr/lib et consort).
Encore heureux! /usr/lib est géré par le gestionaire de package de la distribution, il ne faut pas y mettre des trucs à la main. Quant à /usr/local/lib, ça devient vite le bordel si tu y mets les libs directement.
Quand on installe un programme à la main, c'est très bien de l'installer dans un répertoire particulier à lui, et de symlinker sous /usr/local/ les parties publiques (exécutables, pages de man, libs si elles sont vraiment faites pour être employées de l'extérieur). Comme ça, tu sais trivialement à quel package appartient quel fichier, et c'est facile de le virer ou d'upgrader ou même de faire cohabiter plusieurs versions.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce cas, ça serait bien de fournir un script de lancement, son absence est le seul reproche que je ferais au programme en question), ou alors mettre un RPATH à la compilation.
On se croirait sous Windows !
Hum, ça fait des lustres que je n'ai pas regardé un windows de près, mais à l'époque, à chaque fois qu'on installait un truc, il allait fourer des dlls à lui dans c:windows, qui se retrouvait pollué de manière anarchique...
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne): - rajouter au fichier /etc/ld.so.conf : /repertoire/installation/wengo
BEURK!!!
Alors qu'il suffit de faire un script wrapper...
Doug713705 :
C'est très moche.
Pas tant que ça.
Cela veut dire que les librairies nécéssaires au fonctionnement de wengo
sont installées dans le repertoire d'installation de wengo et non pas avec
les autres librairies (généralement installées dans /usr/lib et consort).
Encore heureux! /usr/lib est géré par le gestionaire de package de la
distribution, il ne faut pas y mettre des trucs à la main. Quant à
/usr/local/lib, ça devient vite le bordel si tu y mets les libs directement.
Quand on installe un programme à la main, c'est très bien de l'installer
dans un répertoire particulier à lui, et de symlinker sous /usr/local/ les
parties publiques (exécutables, pages de man, libs si elles sont vraiment
faites pour être employées de l'extérieur). Comme ça, tu sais trivialement à
quel package appartient quel fichier, et c'est facile de le virer ou
d'upgrader ou même de faire cohabiter plusieurs versions.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce cas,
ça serait bien de fournir un script de lancement, son absence est le seul
reproche que je ferais au programme en question), ou alors mettre un RPATH
à la compilation.
On se croirait sous Windows !
Hum, ça fait des lustres que je n'ai pas regardé un windows de près, mais à
l'époque, à chaque fois qu'on installait un truc, il allait fourer des dlls
à lui dans c:windows, qui se retrouvait pollué de manière anarchique...
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne):
- rajouter au fichier /etc/ld.so.conf :
/repertoire/installation/wengo
Cela veut dire que les librairies nécéssaires au fonctionnement de wengo sont installées dans le repertoire d'installation de wengo et non pas avec les autres librairies (généralement installées dans /usr/lib et consort).
Encore heureux! /usr/lib est géré par le gestionaire de package de la distribution, il ne faut pas y mettre des trucs à la main. Quant à /usr/local/lib, ça devient vite le bordel si tu y mets les libs directement.
Quand on installe un programme à la main, c'est très bien de l'installer dans un répertoire particulier à lui, et de symlinker sous /usr/local/ les parties publiques (exécutables, pages de man, libs si elles sont vraiment faites pour être employées de l'extérieur). Comme ça, tu sais trivialement à quel package appartient quel fichier, et c'est facile de le virer ou d'upgrader ou même de faire cohabiter plusieurs versions.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce cas, ça serait bien de fournir un script de lancement, son absence est le seul reproche que je ferais au programme en question), ou alors mettre un RPATH à la compilation.
On se croirait sous Windows !
Hum, ça fait des lustres que je n'ai pas regardé un windows de près, mais à l'époque, à chaque fois qu'on installait un truc, il allait fourer des dlls à lui dans c:windows, qui se retrouvait pollué de manière anarchique...
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne): - rajouter au fichier /etc/ld.so.conf : /repertoire/installation/wengo
BEURK!!!
Alors qu'il suffit de faire un script wrapper...
Doug713705
Le dimanche 11 février 2007 21:12, Luc Habert s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Encore heureux! /usr/lib est géré par le gestionaire de package de la distribution, il ne faut pas y mettre des trucs à la main. Quant à /usr/local/lib, ça devient vite le bordel si tu y mets les libs directement.
Rien ne dit que ce prog n'a pas été installé avec le gestionnaire de paquet de la distrib.
Quand on installe un programme à la main, c'est très bien de l'installer dans un répertoire particulier à lui, et de symlinker sous /usr/local/ les parties publiques (exécutables, pages de man, libs si elles sont vraiment faites pour être employées de l'extérieur). Comme ça, tu sais trivialement à quel package appartient quel fichier, et c'est facile de le virer ou d'upgrader ou même de faire cohabiter plusieurs versions.
Bah a titre personnel c'est ce que je fais mais bon... Je ne connais pas le niveau technique ni même la distrib de Graison.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce cas, ça serait bien de fournir un script de lancement, son absence est le seul reproche que je ferais au programme en question), ou alors mettre un RPATH à la compilation.
Ca je l'accorde volontiers.
On se croirait sous Windows !
Hum, ça fait des lustres que je n'ai pas regardé un windows de près, mais à l'époque, à chaque fois qu'on installait un truc, il allait fourer des dlls à lui dans c:windows, qui se retrouvait pollué de manière anarchique...
Ben il arrive aussi fréquemment que chaque programme arrive avec toutes ses libs installées dans son repertoire. Ainsi si tu as 36 progs qui dépendent de la même lib tu te retrouve avec 36 fois la même lib sur ton disque.
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne): - rajouter au fichier /etc/ld.so.conf : /repertoire/installation/wengo
BEURK!!!
C'est la première idée qui m'est venue.
Alors qu'il suffit de faire un script wrapper...
Aussi.
-- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
Le dimanche 11 février 2007 21:12, Luc Habert s'est exprimé de la sorte sur
fr.comp.os.linux.configuration :
Encore heureux! /usr/lib est géré par le gestionaire de package de la
distribution, il ne faut pas y mettre des trucs à la main. Quant à
/usr/local/lib, ça devient vite le bordel si tu y mets les libs
directement.
Rien ne dit que ce prog n'a pas été installé avec le gestionnaire de paquet
de la distrib.
Quand on installe un programme à la main, c'est très bien de l'installer
dans un répertoire particulier à lui, et de symlinker sous /usr/local/ les
parties publiques (exécutables, pages de man, libs si elles sont vraiment
faites pour être employées de l'extérieur). Comme ça, tu sais trivialement
à quel package appartient quel fichier, et c'est facile de le virer ou
d'upgrader ou même de faire cohabiter plusieurs versions.
Bah a titre personnel c'est ce que je fais mais bon... Je ne connais pas le
niveau technique ni même la distrib de Graison.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce cas,
ça serait bien de fournir un script de lancement, son absence est le seul
reproche que je ferais au programme en question), ou alors mettre un RPATH
à la compilation.
Ca je l'accorde volontiers.
On se croirait sous Windows !
Hum, ça fait des lustres que je n'ai pas regardé un windows de près, mais
à l'époque, à chaque fois qu'on installait un truc, il allait fourer des
dlls à lui dans c:windows, qui se retrouvait pollué de manière
anarchique...
Ben il arrive aussi fréquemment que chaque programme arrive avec toutes ses
libs installées dans son repertoire. Ainsi si tu as 36 progs qui dépendent
de la même lib tu te retrouve avec 36 fois la même lib sur ton disque.
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne):
- rajouter au fichier /etc/ld.so.conf :
/repertoire/installation/wengo
BEURK!!!
C'est la première idée qui m'est venue.
Alors qu'il suffit de faire un script wrapper...
Aussi.
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Le dimanche 11 février 2007 21:12, Luc Habert s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Encore heureux! /usr/lib est géré par le gestionaire de package de la distribution, il ne faut pas y mettre des trucs à la main. Quant à /usr/local/lib, ça devient vite le bordel si tu y mets les libs directement.
Rien ne dit que ce prog n'a pas été installé avec le gestionnaire de paquet de la distrib.
Quand on installe un programme à la main, c'est très bien de l'installer dans un répertoire particulier à lui, et de symlinker sous /usr/local/ les parties publiques (exécutables, pages de man, libs si elles sont vraiment faites pour être employées de l'extérieur). Comme ça, tu sais trivialement à quel package appartient quel fichier, et c'est facile de le virer ou d'upgrader ou même de faire cohabiter plusieurs versions.
Bah a titre personnel c'est ce que je fais mais bon... Je ne connais pas le niveau technique ni même la distrib de Graison.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce cas, ça serait bien de fournir un script de lancement, son absence est le seul reproche que je ferais au programme en question), ou alors mettre un RPATH à la compilation.
Ca je l'accorde volontiers.
On se croirait sous Windows !
Hum, ça fait des lustres que je n'ai pas regardé un windows de près, mais à l'époque, à chaque fois qu'on installait un truc, il allait fourer des dlls à lui dans c:windows, qui se retrouvait pollué de manière anarchique...
Ben il arrive aussi fréquemment que chaque programme arrive avec toutes ses libs installées dans son repertoire. Ainsi si tu as 36 progs qui dépendent de la même lib tu te retrouve avec 36 fois la même lib sur ton disque.
En toute logique, pour éviter cette manip (pas sûr que ça fonctionne): - rajouter au fichier /etc/ld.so.conf : /repertoire/installation/wengo
BEURK!!!
C'est la première idée qui m'est venue.
Alors qu'il suffit de faire un script wrapper...
Aussi.
-- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
G-raison
Doug713705 wrote:
Rien ne dit que ce prog n'a pas été installé avec le gestionnaire de paquet de la distrib.
Non, ça ne marchait pas ce qui était dans le gestionnaire de paquet pour mon cas. J'ai installé les binaires si je ne me trompe.
Bah a titre personnel c'est ce que je fais mais bon... Je ne connais pas le niveau technique ni même la distrib de Graison.
Mandriva One installée sur le DD. (2.6.17-5mdvlegacy) Pour l'instant j'en suis là depuis quelques temps.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce cas, ça serait bien de fournir un script de lancement, son absence est le seul reproche que je ferais au programme en question), ou alors mettre un RPATH à la compilation.
Ca je l'accorde volontiers.
Bon, c'est vrai que ce serait mieux avec un scripte de lancement. Je vais y jeter un oeil, ce n'est pas dit que je vais faire quelque chose de propre.
-- @+ gr
Doug713705 wrote:
Rien ne dit que ce prog n'a pas été installé avec le gestionnaire de
paquet de la distrib.
Non, ça ne marchait pas ce qui était dans le gestionnaire de paquet pour mon
cas.
J'ai installé les binaires si je ne me trompe.
Bah a titre personnel c'est ce que je fais mais bon... Je ne connais pas
le niveau technique ni même la distrib de Graison.
Mandriva One installée sur le DD. (2.6.17-5mdvlegacy)
Pour l'instant j'en suis là depuis quelques temps.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce
cas, ça serait bien de fournir un script de lancement, son absence est le
seul reproche que je ferais au programme en question), ou alors mettre un
RPATH à la compilation.
Ca je l'accorde volontiers.
Bon, c'est vrai que ce serait mieux avec un scripte de lancement.
Je vais y jeter un oeil, ce n'est pas dit que je vais faire quelque chose de
propre.
Rien ne dit que ce prog n'a pas été installé avec le gestionnaire de paquet de la distrib.
Non, ça ne marchait pas ce qui était dans le gestionnaire de paquet pour mon cas. J'ai installé les binaires si je ne me trompe.
Bah a titre personnel c'est ce que je fais mais bon... Je ne connais pas le niveau technique ni même la distrib de Graison.
Mandriva One installée sur le DD. (2.6.17-5mdvlegacy) Pour l'instant j'en suis là depuis quelques temps.
Pour des libs privées, on peut utiliser LD_LIBRARY_PATH (mais dans ce cas, ça serait bien de fournir un script de lancement, son absence est le seul reproche que je ferais au programme en question), ou alors mettre un RPATH à la compilation.
Ca je l'accorde volontiers.
Bon, c'est vrai que ce serait mieux avec un scripte de lancement. Je vais y jeter un oeil, ce n'est pas dit que je vais faire quelque chose de propre.
-- @+ gr
geo cherchetout
Le 11.02.2007 20:33, *G-raison* a écrit fort à propos :
L'executable devrait être qtwengophone. Visiblement j'ai du foiré l'installation. Malgrès tout ça marche.
Bonsoir,
Tu en es encore à la version du 14 décembre 2006 ? Il y a eu quelques petits progrès depuis, notamment en ce qui concerne le mode de lancement de l'application. Pour ma part, j'essaie quasi quotidiennement la dernière des « nightlybuilds » que je récupère ici : http://wengofiles.wengo.fr/nightlybuilds/binary/NG/GNULinux/2.1/ On décompresse l'archive n'importe où dans son home et on exécute le script wengophone.sh qu'on trouve dans le répertoire wengophone-ng-binary-latest ainsi créé. Ce script contient ce qu'il faut pour qu'on n'ait pas à préciser manuellement la valeur de LD_LIBRARY_PATH ni le nom du véritable exécutable qtwengophone. Dans tous les cas, je crois devoir dire à la décharge de Wengo qu'il ne s'agit pas d'une véritable installation, avec les bibliothèques par ci, les exécutables par là, le menu pour kde, l'icône sur le bureau, que sais-je encore. Cette étape sera pour plus tard. Peut-être bientôt puisqu'il semble que les développeurs y ont encore travaillé aujourd'hui dimanche. :-) Quand tu auras un moment, je souhaite faire un essai avec toi. J'ai constaté à mes dépends qu'un compte Wengo inutilisé se trouve désactivé automatiquement au bout d'un certain temps.
Amicalement.
Le 11.02.2007 20:33, *G-raison* a écrit fort à propos :
L'executable devrait être qtwengophone.
Visiblement j'ai du foiré l'installation.
Malgrès tout ça marche.
Bonsoir,
Tu en es encore à la version du 14 décembre 2006 ? Il y a eu quelques
petits progrès depuis, notamment en ce qui concerne le mode de lancement
de l'application. Pour ma part, j'essaie quasi quotidiennement la
dernière des « nightlybuilds » que je récupère ici :
http://wengofiles.wengo.fr/nightlybuilds/binary/NG/GNULinux/2.1/ On
décompresse l'archive n'importe où dans son home et on exécute le script
wengophone.sh qu'on trouve dans le répertoire
wengophone-ng-binary-latest ainsi créé. Ce script contient ce qu'il faut
pour qu'on n'ait pas à préciser manuellement la valeur de
LD_LIBRARY_PATH ni le nom du véritable exécutable qtwengophone.
Dans tous les cas, je crois devoir dire à la décharge de Wengo qu'il ne
s'agit pas d'une véritable installation, avec les bibliothèques par ci,
les exécutables par là, le menu pour kde, l'icône sur le bureau, que
sais-je encore. Cette étape sera pour plus tard. Peut-être bientôt
puisqu'il semble que les développeurs y ont encore travaillé aujourd'hui
dimanche. :-)
Quand tu auras un moment, je souhaite faire un essai avec toi. J'ai
constaté à mes dépends qu'un compte Wengo inutilisé se trouve désactivé
automatiquement au bout d'un certain temps.
Le 11.02.2007 20:33, *G-raison* a écrit fort à propos :
L'executable devrait être qtwengophone. Visiblement j'ai du foiré l'installation. Malgrès tout ça marche.
Bonsoir,
Tu en es encore à la version du 14 décembre 2006 ? Il y a eu quelques petits progrès depuis, notamment en ce qui concerne le mode de lancement de l'application. Pour ma part, j'essaie quasi quotidiennement la dernière des « nightlybuilds » que je récupère ici : http://wengofiles.wengo.fr/nightlybuilds/binary/NG/GNULinux/2.1/ On décompresse l'archive n'importe où dans son home et on exécute le script wengophone.sh qu'on trouve dans le répertoire wengophone-ng-binary-latest ainsi créé. Ce script contient ce qu'il faut pour qu'on n'ait pas à préciser manuellement la valeur de LD_LIBRARY_PATH ni le nom du véritable exécutable qtwengophone. Dans tous les cas, je crois devoir dire à la décharge de Wengo qu'il ne s'agit pas d'une véritable installation, avec les bibliothèques par ci, les exécutables par là, le menu pour kde, l'icône sur le bureau, que sais-je encore. Cette étape sera pour plus tard. Peut-être bientôt puisqu'il semble que les développeurs y ont encore travaillé aujourd'hui dimanche. :-) Quand tu auras un moment, je souhaite faire un essai avec toi. J'ai constaté à mes dépends qu'un compte Wengo inutilisé se trouve désactivé automatiquement au bout d'un certain temps.
Amicalement.
G-raison
geo cherchetout wrote:
Quand tu auras un moment, je souhaite faire un essai avec toi. J'ai constaté à mes dépends qu'un compte Wengo inutilisé se trouve désactivé automatiquement au bout d'un certain temps.
Ok, j'espère avoir un moment dans la journée de demain. Je ne peux pas laisser Ekiga et Wengo en même temps Dommage. Et la version 0.99 marchait bien avec mes soeurs par exemple mais le son était mal.
Amicalement.
De même :-) -- @+ gr
geo cherchetout wrote:
Quand tu auras un moment, je souhaite faire un essai avec toi. J'ai
constaté à mes dépends qu'un compte Wengo inutilisé se trouve désactivé
automatiquement au bout d'un certain temps.
Ok, j'espère avoir un moment dans la journée de demain.
Je ne peux pas laisser Ekiga et Wengo en même temps
Dommage.
Et la version 0.99 marchait bien avec mes soeurs par exemple mais le son
était mal.
Quand tu auras un moment, je souhaite faire un essai avec toi. J'ai constaté à mes dépends qu'un compte Wengo inutilisé se trouve désactivé automatiquement au bout d'un certain temps.
Ok, j'espère avoir un moment dans la journée de demain. Je ne peux pas laisser Ekiga et Wengo en même temps Dommage. Et la version 0.99 marchait bien avec mes soeurs par exemple mais le son était mal.
