Bah y'a certainement une option dans le ./configure d'uMurmur pour préciser le chemin de protobuf-c, après faut voir précisément ce qu'il attend comme chemin, des fois il suffit de dire /usr/local/include et il rajoute le reste tout seul, des fois il veut juste /usr ou /usr/local, des fois faut le chemin jusqu'au dossier qui contient les headers, après rebelotte pour les .so/.a dans /usr/local/lib...

Bon je viens de regarder uMurmur, y'a pas moyen de lui préciser où chercher ses dépendances, c'est mignon.

Apparemment il va chercher dans /usr/include au lieu de /usr/local/include, la méthode rapide et déguelasse c'est ça :

cd /usr/include
ln -s ../local/include/google/ google
cd /usr/lib
ln -s ../local/lib/libprotobuf-c.* .

(Oui je te devance pour /lib parce que t'auras le même problème une fois qu'il a trouvé les includes.)

Bon t'es pas sorti avec ça, il veut libconfig après, je te laisse gratter.

Et non, pkg_add libconfig ne suffit pas.

Sinon si tu cherches un fusil à pompe calibre 12, on peut s'arranger tu sais.

...
Je déprime, je ne pensais pas que c'était aussi bordélique de compiler un truc externe sur BSD...

Note que si le ./configure marche correctement, ça ne veut pas dire que le makefile ira chercher les mêmes fichiers aux mêmes endroits que le ./configure a détecté. Oui, c'est complètement stupide. Et ça veut dire que même une fois que le ./configure aura fini avec succès, tu devras encore faire joujou avec /usr/include et des liens symboliques pour que le gmake passe.

Jail n'existe pas sous NetBSD me semble t-il

Je fais ça dans quelques minutes. Hormis ce problème de localisation, je ne risque pas de rencontrer d'autre soucis ?

Ah ok, j'ai pas finis donc

http://pkgsrc.se/wip/umurmur Et dire qu'un mec l'avait fait jusqu'à 0.2.10 mais que la dernière mise à jour date de début 2013, pourquoi les gens délaissent comme ça les projets ?

De sûr en faisant les liens qui vont bien à chaque header/librairie non trouvée, j'ai pu compiler et installer uMurmur.

1. umurmurd -h

uMurmur version 0.2.15 ('Drool'). Mumble protocol 1.2.4

Après faut lui passer des options pour le lancer et tout je connais pas moi donc je ne sais pas si ça marche vraiment, mais déjà gmake finit sans erreurs et l'help print bien.

Et t'as vraiment besoin des ajouts de la 0.2.15 par rapport à la 0.2.10 ? Si ça respecte SemVer, c'est juste des corrections de bugs, donc si y'a rien de critique dans ton environnement ça devrait faire le job ?

Ça prend le temps de maintenir des paquets, et début 2013 ça a pas l'air très vieux quand même, surtout si y'a pas eu de gros changements depuis... à mon avis tant que personne n'a pas fondamentalement besoin des nouveautés de la 0.2.15 personne ne mettra à jour le port. À moins que tu aies envie de le faire ?

J'aimerai bien le faire si je savais le faire. Mais avant d'en être capable, j'ai du boulot pour savoir faire une telle chose. Je serais franchement chaud pour être maintainer de NetBSD mais j'ai intérêt à bosser sévère avant.

Je compte bien le faire

Sinon, pour les dernières versions, non, j'en ai pas besoin, c'était pour le principe de le faire au moins une fois, c'est tombé sur ce soft

En tout cas, j'espère en être capable comme toi

Tiens sinon en solution un peu plus propre, mais ça marche pas toujours selon les softs :

.∕configure CFLAGS='-I/usr/local/include -L/usr/local/lib -I/usr/pkg/include -L/usr/pkg/lib'

Ça va dire au soft d'aller chercher ses dépendances aussi dans /usr/local et /usr/pkg (au lien de faire des liens dans /usr en dur). Si le ./configure et le makefile le supportent, c'est la « bonne » solution. Ça résoudra pas tous tes problèmes malheureusement.

C'est la bonne solution en règle général donc ?

Entre gmake, et make avec flags + d'autre problèmes...

Est-ce que c'est quelque chose de compliquer de "compiler" (je ne suis pas sur du mot) comme ce que font les autres mainteneur officiels des paquets ?

D'ailleurs, tu peux regarder pourquoi libdrm ne se compile pas sous NetBSD ? J'ai absolument RIEN trouvé sur le net, hormis des mails sans réponse, j'ai aussi fait un rapport de bug histoire d'avoir une réponse mais rien.

Je suis dessus depuis un moment, le paquet est activement mis à jour donc le problème doit venir de moi, il parle de conflit :

ld: warning: libdrm.so.3, needed by
/usr/pkgsrc/x11/libdrm/work/.buildlink/lib/libdrm_
intel.so,
may conflict with
libdrm.so.2
test_decode.o: In function 'main':
test_decode.c:(.text+0x191): undefined reference to
'drm_intel_decode_context_alloc'
test_decode.c:(.text+0x1bd): undefined reference to
'drm_intel_decode_context_free'
test_decode.c:(.text+0x20b): undefined reference to
'drm_intel_decode_set_batch_pointer'
test_decode.c:(.text+0x218): undefined reference to
'drm_intel_decode_set_output_file'
test_decode.c:(.text+0x220): undefined reference to 'drm_intel_decode'

• • Error code 1

Stop.
make: stopped in /usr/pkgsrc/x11/libdrm/work/libdrm-2.4.56/intel

• • Error code 1

Stop.
make: stopped in /usr/pkgsrc/x11/libdrm/work/libdrm-2.4.56

• • Error code 1

Stop.
make: stopped in /usr/pkgsrc/x11/libdrm/work/libdrm-2.4.56

• • Error code 1

Stop.
make: stopped in /usr/pkgsrc/x11/libdrm

Du coup pas d'interface graphique, tu aurais une idée ? Vu que tu as une VM, tu pourrais tester ?

En règle générale non. Des fois le ./configure t'oblige à lui donner des arguments type --with-libfoo=/usr/local/include, des fois tu peux lui donner les CFLAGS directement, mais des fois il veut aussi des LDFLAGS, d'autres fois c'est un nom plus random.

Et même si le ./configure est passé avec ce que tu lui a donné, le make peut quand même se vautrer complètement et à nouveau tu regardes ce que tu peux passer comme options au makefile pour linker proprement, voir pire, éditer le makefile généré par les autotools, mais faut clairement être maso pour ça, je l'ai fait une fois pour compiler PHP 4 mais jamais je remets le nez là dedans (ololz même avec des gants MAPA ).

Donc y'a le moment où ça te les brises au points ou tu te dis « je vais faire des liens symbolique en mode gros porc dans /usr/{include,lib} ».

Compiler c'est ce que t'es en train de faire indirectement, quand tu lances make y'a des règles de compilations qui disent ce qu'il faut faire pour compiler un .c en .o, puis après linker les .o en une librairie ou un exécutable. Honnêtement le plus dur, et c'est sur ça que tu es en train de galérer, c'est de configurer les scripts de compilation/installation. Installer les dépendances, trouver les chemins qui vont bien pour les include/lib, et faire en sorte que le ./configure et make trouvent leur petits là dedans.

Mais quand c'est bien fait, c'est juste histoire d'installer les bonnes dépendances, de définire le type de make à utiliser, et de modifier ce qu'il faut dans les CFLAGS/LDFLAGS. Si tu regardes le package NetBSD de protobuf-c, ça se résume à ça :

http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/protobuf-c/Makefile?revision=1.1&view=markup

Et le bsd.pkg.mk doit déjà savoir comment faire selon les macros définies ; utiliser ./configure && gmake si GNU_CONFIGURE est à yes, ajouter les CFLAGS/LDFLAGS du système quand on compile du C/C++, etc.

Handylinux est seulement dispo en Français et en Anglais?

Bonjour, je recherche un moyen de communication écrit entre windows/debian stable/android/windows phone

J'avais pensé à IRC mais cela me semble trop "rudimentaires", dès que je ne suis plus devant l'application je suis déconnecté
pas de notifications non plus :/

Auriez vous une idée? Un meilleur client IRC?

Essaie XMPP. Pidgin est sympa pour ça sur desktop, par contre pour les mobiles aucune idée, mais il doit sûrement y avoir des clients.

Ok merci