Compilation de paquet debian à partir de sources (delta3d, HawkNL)

16ar · Le 23/02/2007, à 19:39

Bonjour à tous,

Je souhaite compiler delta3d pour pouvoir développer dessus.
Il y'a un tuto sur le site officiel pour expliquer comment l'installer : http://www.delta3d.org/article.php?story=20060821181211777&topic=tutorials

Seulement, le tuto utilise des make/make install. J'aurai préféré un truc plus à la sauce debian, a base de .deb.

Pour les paquets déja présent dans ubuntu mais dont il manquait une feature (un .so, une option de compilation, ...) tout s'est reglé par un :

sudo apt-get source <le nom du paquet>
cd <le nom du paquet>-version
<changement des options de compilation etc>
sudo dpkg-checkbuilddeps
sudo dpkg-buildpackage

Mais pour les paquets en dehors d'Ubuntu, j'ai des soucis lors de la compilation. J'ai suivi le tutorial http://doc.ubuntu-fr.org/tutoriel/creer_un_paquet?s=construire%20paquet
J'ai exactement 2 soucis de compilation. J'ai testé avec HawkNL (une librairie contenant une 10 aine de fichiers sources) et replicantbody étant donné qu'elles sont indépendantes.

Pour les 2, le plantage se situe au niveau du : sudo pbuilder build *dsc

16ar · Le 23/02/2007, à 21:49

Hop, des détails vous aideront surement mieux

HawkNL :

# Add here commands to install the package into debian/tmp
/usr/bin/make -f makefile.linux install
DESTDIR=/tmp/buildd/hawknl-1.6.8/debian/tmp
make[1]: Entering directory `/tmp/buildd/hawknl-1.6.8'
cd src;\
       make -f makefile.linux install
make[2]: Entering directory `/tmp/buildd/hawknl-1.6.8/src'
cp libNL.so.1.6.8 /usr/lib
cp: cannot create regular file `/usr/lib/libNL.so.1.6.8': Permission denied
make[2]: *** [install] Error 1
make[2]: Leaving directory `/tmp/buildd/hawknl-1.6.8/src'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/tmp/buildd/hawknl-1.6.8'
make: *** [install] Error 2
pbuilder: Failed autobuilding of package
 -> Aborting with an error
 -> unmounting dev/pts filesystem
 -> unmounting proc filesystem
 -> cleaning the build env
   -> removing directory /var/cache/pbuilder/build//16163 and its
subdirectories

Je n'ai mis que la fin, la compilation (make) des fichiers a bien
reussi. C'est au niveau de l'install que ca foire pour une histoire de
droits.
J'ai essayé de voir dans l'environnement de compilation avec un

sudo pbuilder login

Seulement, root a bien les droits rwx sur /usr/local/lib ... Donc je
ne comprends pas

Et pour replicantbody, le probleme vient d'une option de
compilation/paquet manquant. Mais je ne sais pas quoi :

# Add here commands to configure the package.
autoreconf --install --force
acinclude.m4:43: warning: underquoted definition of MDL_HAVE_OPENGL
 run info '(automake)Extending aclocal'
 or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
acinclude.m4:152: warning: underquoted definition of MDL_CHECK_LIBM
configure.in:27: error: possibly undefined macro: AC_PROG_LIBTOOL
     If this token and others are legitimate, please use m4_pattern_allow.
     See the Autoconf documentation.
configure.in:33: error: possibly undefined macro: AC_ENABLE_SHARED
configure.in:37: error: possibly undefined macro: AC_ENABLE_STATIC
autoreconf2.50: /usr/bin/autoconf failed with exit status: 1
make: *** [configure-stamp] Error 1
pbuilder: Failed autobuilding of package
 -> Aborting with an error
 -> unmounting dev/pts filesystem
 -> unmounting proc filesystem
 -> cleaning the build env
   -> removing directory /var/cache/pbuilder/build//17124 and its
subdirectories

J'ai rajouté le

autoreconf --install --force

Dans le debian/rules car il était nécéssaire (indiqué dans le INSTALL
de replicantbody)
En tout cas, ca deconne dans l'environnement pbuild, alors que un
autoreconf --force --install puis un ./configure, ca passe sur mon
ubuntu.
Donc je pense qu'il manque un paquet (j'ai bien rajouté autoreconf
dans l'environnement pbuilder).

Si quelqu'un a une idée ? Merci

mr_pouit · Le 24/02/2007, à 20:59

Bonsoir,

16ar a écrit :

cp: cannot create regular file `/usr/lib/libNL.so.1.6.8': Permission denied

C'est un classique des Makefiles mal faits
Il ne tient pas compte du $(DESTDIR) fourni en paramètre, et essaie d'installer directement dans /usr, et le système de création de paquets n'a pas le droit de le faire.
Il faut que tu corriges le Makefile

16ar a écrit :

Donc je pense qu'il manque un paquet (j'ai bien rajouté autoreconf
dans l'environnement pbuilder).

Essaie d'ajouter libtool (sans grande conviction )

16ar · Le 24/02/2007, à 22:13

mr_pouit a écrit :

Bonsoir,
16ar a écrit :
cp: cannot create regular file `/usr/lib/libNL.so.1.6.8': Permission denied
C'est un classique des Makefiles mal faits
Il ne tient pas compte du $(DESTDIR) fourni en paramètre, et essaie d'installer directement dans /usr, et le système de création de paquets n'a pas le droit de le faire.
Il faut que tu corriges le Makefile

Du coup, je dois remplacer /usr par $(DESTDIR) ?

mr_pouit a écrit :

16ar a écrit :
Donc je pense qu'il manque un paquet (j'ai bien rajouté autoreconf
dans l'environnement pbuilder).
Essaie d'ajouter libtool (sans grande conviction )

libtool a fonctionné ! Autoreconf a passé a l'étape suivante

Le configure est passé, mais y'a eu une erreur a la compilation. Dépendance manquante, ca doit etre libcal3D-dev, je pense que je devrais m'en sortir, merci beaucoup !

mr_pouit · Le 24/02/2007, à 22:34

16ar a écrit :

Du coup, je dois remplacer /usr par $(DESTDIR) ?

$(DESTDIR)/usr je dirais

16ar · Le 24/02/2007, à 23:23

Je suis désolé, mais je ne sais pas exactement quoi faire. Les makefile et moi, on n'est pas super pote ^^. J'aimerai bien, mais bon
Voila le makefile contenu dans src/ de hawknl

CC = gcc
AR = ar cru
RANLIB = ranlib
MAJOR_VERSION = 1
MINOR_VERSION = 6
PATCH_LEVEL = 8
VERSION = $(MAJOR_VERSION).$(MINOR_VERSION).$(PATCH_LEVEL)
LIBDIR = /usr/lib
INCDIR = /usr/include
INCLUDE = -I../include
OUTPUT = libNL.so.$(VERSION)
LIBNAME = NL
STATIC = libNL.a
OPTFLAGS = -funroll-all-loops -ffast-math -fomit-frame-pointer -O2 -D_GNU_SOURCE -D_REENTRANT
CFLAGS = -Wall -fPIC $(INCLUDE) $(OPTFLAGS)
LIBFLAGS = -shared -Wl,-soname,NL.so.$(MAJOR_VERSION).$(MINOR_VERSION) -rdynamic -lpthread
OBJECTS = crc.o errorstr.o nl.o sock.o group.o loopback.o err.o thread.o mutex.o condition.o nltime.o

all: $(OBJECTS)
        $(CC) -o $(OUTPUT) $(OBJECTS) $(LIBFLAGS) $(CFLAGS)
        $(AR) $(STATIC) $(OBJECTS)
        $(RANLIB) $(STATIC)

nl.o : nlinternal.h nl.c
sock.o : nlinternal.h sock.h sock.c
errorstr.o : nlinternal.h errorstr.c
crc.o : ../include/nl.h crc.c
group.o : nlinternal.h group.c
loopback.o : nlinternal.h loopback.h loopback.c
err.o : nlinternal.h err.c
thread.o : nlinternal.h thread.c
mutex.o : nlinternal.h mutex.c
condition.0 : nlinternal.h condition.c
nltime.o : nlinternal.h nltime.c

install:
        cp $(OUTPUT) $(LIBDIR)
        cp $(STATIC) $(LIBDIR)
        chmod 755 $(LIBDIR)/$(OUTPUT)
        ln -s $(LIBDIR)/$(OUTPUT) $(LIBDIR)/lib$(LIBNAME).so.$(MAJOR_VERSION).$(MINOR_VERSION)
        ln -s $(LIBDIR)/$(OUTPUT) $(LIBDIR)/lib$(LIBNAME).so.$(MAJOR_VERSION)
        ln -s $(LIBDIR)/$(OUTPUT) $(LIBDIR)/lib$(LIBNAME).so
        ln -s $(LIBDIR)/$(OUTPUT) $(LIBDIR)/$(LIBNAME).so
        cp ../include/nl.h $(INCDIR)/nl.h
        chmod 644 $(INCDIR)/nl.h
        @echo ""
        @echo "*************************************************"
        @echo "* Installed HawkNL.                             *"
        @echo "* Remember to run /sbin/ldconfig before using   *"
        @echo "* the library, you may also want to check that  *"
        @echo "* $(LIBDIR) is included in /etc/ld.so.conf      *"
        @echo "* You must be root to run ldconfig.             *"
        @echo "*************************************************"

uninstall:
        rm -f $(LIBDIR)/$(OUTPUT) $(LIBDIR)/lib$(LIBNAME).so.$(MAJOR_VERSION).$(MINOR_VERSION)
        rm -f $(LIBDIR)/lib$(LIBNAME).so.$(MAJOR_VERSION).$(MINOR_VERSION)
        rm -f $(LIBDIR)/lib$(LIBNAME).so.$(MAJOR_VERSION)
        rm -f $(LIBDIR)/lib$(LIBNAME).so
        rm -f $(LIBDIR)/$(LIBNAME).so
        rm -f $(LIBDIR)/$(STATIC)
        rm -f $(INCDIR)/nl.h

.PHONY : clean
clean:

Comme dit, y'a tres peu de fichiers a compiler (moins d'une dizaine). Du coup, je pense que c'est un bon projet pour apprendre pbuilder etc ^^
Seulement, malgré ton indication, je ne vois pas quoi faire.

(J'ai vu ton topic sur le rajout de paquet dans ubuntu, superbe initiative D'ailleurs, je pourrais peut être aider pour l'ajout de delta3d (qui est dans la liste) et toutes les dépendances, mais bon, je n'ai pas encore lu la ubuntu/debian policy (qui est immense, il faut le dire) et du coup, j'ai peur de faire des paquets de merde )

mr_pouit · Le 25/02/2007, à 00:09

Par exemple, remplacer les 2 lignes sous la cible install: par :

install:
        cp $(OUTPUT) $(DESTDIR)/$(LIBDIR)
        cp $(STATIC) $(DESTDIR)/$(LIBDIR)

et il mettra les fichiers au bon endroit.

Mais ensuite, il y aura un autre problème, au moment de faire les liens :

        ln -s $(LIBDIR)/$(OUTPUT) $(LIBDIR)/lib$(LIBNAME).so.$(MAJOR_VERSION).$(MINOR_VERSION)
        ln -s $(LIBDIR)/$(OUTPUT) $(LIBDIR)/lib$(LIBNAME).so.$(MAJOR_VERSION)
        ln -s $(LIBDIR)/$(OUTPUT) $(LIBDIR)/lib$(LIBNAME).so
        ln -s $(LIBDIR)/$(OUTPUT) $(LIBDIR)/$(LIBNAME).so

ça va échouer de même (problème de permissions). Mais, si on rajoute $(DESTDIR) de la même façon, le lien symbolique sera bancal, et ne fonctionnera pas sur un système normal (à cause du DESTDIR) :

        ln -s $(DESTDIR)/$(LIBDIR)/$(OUTPUT) $(DESTDIR)/$(LIBDIR)/$(LIBNAME).so

équivaut à

        ln -s /tmp/buildd/hawknl-1.6.8/debian/tmp/usr/lib/libNL.so.1.6.8 /tmp/buildd/hawknl-1.6.8/debian/tmp/usr/lib/NL.so

et le dossier /tmp/buildd/... n'existe que dans le pbuilder lors de la création du paquet

Après, il y a plusieurs solutions, par exemple, commenter la partie qui crée les liens dans le Makefile, et les créer toi-même dans un fichier debian/links ou encore avec dh_link (je te renvoie à la documentation debian, ou encore à la page de man de dh_link ), ou encore éditer le Makefile et se mettre dans le bon répertoire juste avant de faire les liens (la première solution est mieux ).

Comme dit, y'a tres peu de fichiers a compiler (moins d'une dizaine). Du coup, je pense que c'est un bon projet pour apprendre pbuilder etc ^^
Seulement, malgré ton indication, je ne vois pas quoi faire.

Et tu tombes sur un Makefile foireux comme celui-là, pas de chance

(J'ai vu ton topic sur le rajout de paquet dans ubuntu, superbe initiative D'ailleurs, je pourrais peut être aider pour l'ajout de delta3d (qui est dans la liste) et toutes les dépendances, mais bon, je n'ai pas encore lu la ubuntu/debian policy (qui est immense, il faut le dire) et du coup, j'ai peur de faire des paquets de merde )

Les ajouts pour feisty sont gelés maintenant, donc tu as encore quelques mois pour t'entraîner.
Et faut pas avoir peur de faire des paquets foireux
Et Si tu as des questions, tu peux venir sur IRC, canal #ubuntu-fr-classroom sur FreeNode, devrait y avoir quelqu'un pour répondre.

16ar · Le 25/02/2007, à 02:35

Je n'ai toujours pas réussi

Avez vous un bon tutorial a m'indiquer, ou presque mieux, une librairie qui ne soit pas dégueulasse et avec pas trop de fichier ?

libode, le makefile ne contient meme pas de target install, faut copier les lib a la main (lu dans le INSTALL ...) et y'a deja trop de fichier a compiler...
Bref, je pense qu'un exemple bien fait avec un makefile court et debian rules bien foutu, ca m'aiderait... Parce que la, je suis dans le flou ...
Y'a un cp qui est censé copier le fichier output, et pourtant le paquet debian est vide ...
Personnellement, je pense qu'il ne copie pas a partir du bon repertoire ... Mais faut faire quoi ? Un cd ? Y'a pas plus propre ?

16ar · Le 08/08/2007, à 15:04

Bon, vu que j'ai un peu trainé sur IRC sur #ubuntu-fr-classroom, mon packaging a avancé

Maintenant, j'ai lu la Debian Policy ainsi que le libpkg-guide et un manuel de tldp (Program Libraries HOWTO, je crois).

La bibliothèque que je veux empaqueter, Delta3D, n'a pas de soname indiqué dans leur librairie, et les librairies sont de forme
libdtCore.so

Pas de numéro de version.

Sachant qu'actuellement, entre 2 releases, la version du projet augmente d'1 version mineure. Et généralement les dépendances entre 2 versions mineures change. Par exemple, pour le passage de Delta3D-1.3.0 a 1.4.0 les dépendances de OpenSceneGraph sont passées de 1.0 a 1.2.

Ainsi, d'apres moi, le soname des librairies changerait a chaque release du nombre mineure vu que l'API est cassée a ce niveau.
Ainsi le soname le plus adapté serait du genre : libdtCore.so.1.3, non ?
(leur politique est la meme que osg, une librairie par namespace, donc dtCore:: = libdtCore)

Voila, je m'en remet a vous, car c tres récent pour moi, et je ne suis pas sur du tout. Or je voudrais leur conseiller la meilleure chose. (Ils n'avaient pas l'air de connaitre l'existance des soname))

Merci !

[EDIT] : lien vers le tableau des dépendances :
http://www.delta3d.org/article.php?story=20050707151113592&topic=docs

Dernière modification par 16ar (Le 08/08/2007, à 15:06)

16ar · Le 08/08/2007, à 18:24

Autre question :
Delta3d vient en plusieurs archives

un zip de sources
un zip de data (modele 3D, textures, sons) pour faire fonctionner les examples contenus dans les sources

Est ce que je dois faire 2 paquets sources avec 2 .orig differents (1 pour chaque zip) ou je réunis les 2 dans un seul .orig (un .orig un peu modifié du coup) ?
Sachant que beaucoup d'exemples sans les data ne serviront a rien. Aucun media ne sera chargé et aucun résultat ne sera visible.

D'autre part, le projet Delta3D fournit pleins de modeles tout fait (non necessaire pour l'execution des exemples, mais peut etrenéanmoins pratique ). Est ce que ca vaut le coup de le packager ?

EDIT : quand je parle de modeles, je parle de modeles 3D en général

Dernière modification par 16ar (Le 09/08/2007, à 15:57)

mr_pouit · Le 10/08/2007, à 20:14

2 orig ça ira bien, avec un Recommends entre les sources et les data.

Et pour le soname, ce n'est pas à toi de le faire, c'est au(x) développeur(s) du logiciel (ainsi que de l'incrémenter correctement en cas de changement de l'API).

16ar · Le 10/08/2007, à 20:54

Oui je sais, mais il ne connaissait pas, donc du coup, c moi qui en sais "plus" que eux. Donc autant que je leur conseille la bonne chose
Apres ca sera dans leur sources a eux, evidemment

Donc d'apres toi, ca serait bon ma proposition vu comment le projet evolue ?

Merci des eclaircissement, mr_pouit, mon sauveur packager

16ar · Le 22/08/2007, à 16:33

D'apres ce que j'ai pu lire de discussion sur la mailing list OpenSceneGraph, le numéro de soname c'est juste un entier qui evolue pour indiquer quelle "version" d'interface. Aucun lien avec la version du paquet source.

Par exemple, OpenSceneGraph, source en version 1.2.0, les differents shared objects sont en version soname 4 (libosg.so.4, libosgDb.so.4, libosgChar.so.4, ...) (en meme temps, je ne suis pas sur que ca soit un bon exemple, car je n'imagine pas que toutes les bibliotheques ont changé d'interface en meme temps)

Donc d'après moi, il faudrait que je conseille aux developpeurs de Delta3d d'utiliser un num de soname a 0, et de l'incrementer a chaque fois que l'interface se casse. Non ?

En te relisant mr_pouit, il faudrait donc 2 .orig. J'imagine qu'il faudra du coup 2 paquets source, et donc 2 debian/ tree. J'ai bon ?

mr_pouit · Le 22/08/2007, à 21:11

Oui (pour le soname et les 2 arbres debian ).

16ar · Le 23/08/2007, à 10:58

Merci bcp mr_pouit

16ar · Le 27/08/2007, à 14:02

Alors j'ai passé un peu de mon temps ce week end a refaire des paquets tout propre tout beau pour les dépendances avant de passer a Delta3D.

J'ai plusieurs question du coup :
- j'ai téléchargé les sources de HawkNL, et le paquet source je l'ai nommé hawknl, jusque la, pas de soucis.
- Le paquet hawknl ne génère qu'une seule bibliotheque .so nommé libNL.so.1.6.8 (avec le soname = NL.so.1.6). J'imagine que je dois renommer le soname libNL.so.1.6, car la notation purement NL.so.1.6 ne fonctionnerait pas de base si la library name serait pareille (/usr/lib/NL.so.1.6), il faut un prefixe lib, non ?
A moins que ca ne soit le library name a changer en NL.so.1.6, avec les liens symboliques du type : NL.so.1 et NL.so, non ?
-- evidemment si je change le soname, il faut que j'en informe upstream j'imagine ? (mais je vais d'abord vérifier comment il a géré ca dans sa version beta 1.7)
- HawkNL génère donc libNL.so.1.6. Seulement, il existe deja un paquet libnl1 (et un libnl1-pre6 d'ailleurs, a peu de chose pres ... lol) Que dois je faire contacter la ml debian/ubuntu pour savoir si je dois renommer la librairie en libHawkNL.so.1.6 ? pour avoir un paquet libhawknl1.6 ?

- autre souci, GNElib est une surcouche a HawkNL, et dans la config de base, il ne génère qu'une archive libgne.a
D'autre part dans le readme.linux, il est indiqué de copier le fichier include/libgnelib.h et lib/libgnelib.a.
Or l'archive générée n'a pas ce nom la. Je suis le README ? ou je garde ce que fait le make ?
Pour le moment, j'ai un paquet libgnelib0 qui n'a pratiquement rien (a part que j'ai quand meme généré un libgnelib.so.0 au cas ou) et un libgnelib0-dev qui contient un libgnelib.a.
Dans le cas d'un .so, il faut 1 paquet du nom du soname, mais quand c'est une librairie statique, on choisit comment ?
Et normalement, il vaut mieux un .so qu'un .a, donc je dois fournir un patch pour générer le .so, c'est ca ?

[EDIT] Dans le svn, le makefile génère un libgnelib.a . Donc c'est bon pour le nom du paquet actuel.

- Derniere question : j'ai des exemples de code pour GNElib. Ou dois je les placer ?
J'ai pensé a un paquet : libgnelib0-examples. Mais est ce cela ? ou plutot le nom du paquet source + -examples ? (genre gnelib-examples). Vu qu'a priori les sources sont liées au biblio de dev, je pense qu'utiliser le nom du paquet de bibliotheque n'est pas si bete. Seulement, gnelib ne génère qu'une bibliotheque. Si elle en générait plusieurs, les sources d'exemples dépendraient des differentes bibliotheques de developpement et 1 seul nom de bibliotheque ne conviendrait pas. Il faudrait utiliser quoi du coup ? le nom du paquet source suivi du numéro de version ? Genre gnelib-0.7-examples (qui dépendrait de libgnelib0-dev et libgnelibdata2-dev par exemple) ?

Merci de m'éclairer. Ca me fait pas mal cogiter et je n'ai pas eu toutes les réponses dans les manuels debian.

Dernière modification par 16ar (Le 27/08/2007, à 17:51)

16ar · Le 05/09/2007, à 17:50

Personne n'a d'idées ? :'(

(up)

mr_pouit · Le 10/09/2007, à 22:14

16ar a écrit :

- j'ai téléchargé les sources de HawkNL, et le paquet source je l'ai nommé hawknl, jusque la, pas de soucis.
- Le paquet hawknl ne génère qu'une seule bibliotheque .so nommé libNL.so.1.6.8 (avec le soname = NL.so.1.6). J'imagine que je dois renommer le soname libNL.so.1.6, car la notation purement NL.so.1.6 ne fonctionnerait pas de base si la library name serait pareille (/usr/lib/NL.so.1.6), il faut un prefixe lib, non ?

le soname = les chiffres seulement.
Et le nom de la lib est correct, sauf si une lib avec le même nom existe déjà dans debian.

- HawkNL génère donc libNL.so.1.6. Seulement, il existe deja un paquet libnl1 (et un libnl1-pre6 d'ailleurs, a peu de chose pres ... lol) Que dois je faire contacter la ml debian/ubuntu pour savoir si je dois renommer la librairie en libHawkNL.so.1.6 ? pour avoir un paquet libhawknl1.6 ?

donc dans ce cas, il faudrait qu'upstream renomme sa lib.

A moins que ca ne soit le library name a changer en NL.so.1.6, avec les liens symboliques du type : NL.so.1 et NL.so, non ?
-- evidemment si je change le soname, il faut que j'en informe upstream j'imagine ? (mais je vais d'abord vérifier comment il a géré ca dans sa version beta 1.7)

Encore une fois, c'est pas à toi de faire ça, c'est à upstream (tu peux très bien tout patcher dans ton paquet, mais bon...).
Et le soname me paraît faux : le soname ne doit pas être relié à la version du logiciel. Là on a le soname 1:6:8 pour la version 1.6.8 de hawknl, ça ne me semble pas correct (cf. http://www.gnu.org/software/libtool/manual.html#Updating-version-info)

- autre souci, GNElib est une surcouche a HawkNL, et dans la config de base, il ne génère qu'une archive libgne.a
D'autre part dans le readme.linux, il est indiqué de copier le fichier include/libgnelib.h et lib/libgnelib.a.
Or l'archive générée n'a pas ce nom la. Je suis le README ? ou je garde ce que fait le make ?
Pour le moment, j'ai un paquet libgnelib0 qui n'a pratiquement rien (a part que j'ai quand meme généré un libgnelib.so.0 au cas ou) et un libgnelib0-dev qui contient un libgnelib.a.
Dans le cas d'un .so, il faut 1 paquet du nom du soname, mais quand c'est une librairie statique, on choisit comment ?
Et normalement, il vaut mieux un .so qu'un .a, donc je dois fournir un patch pour générer le .so, c'est ca ?
[EDIT] Dans le svn, le makefile génère un libgnelib.a . Donc c'est bon pour le nom du paquet actuel.

C'est pas génial les libs statiques.
C'est vraiment à upstream de faire ça, pas à toi.

- Derniere question : j'ai des exemples de code pour GNElib. Ou dois je les placer ?
J'ai pensé a un paquet : libgnelib0-examples. Mais est ce cela ? ou plutot le nom du paquet source + -examples ? (genre gnelib-examples). Vu qu'a priori les sources sont liées au biblio de dev, je pense qu'utiliser le nom du paquet de bibliotheque n'est pas si bete. Seulement, gnelib ne génère qu'une bibliotheque. Si elle en générait plusieurs, les sources d'exemples dépendraient des differentes bibliotheques de developpement et 1 seul nom de bibliotheque ne conviendrait pas. Il faudrait utiliser quoi du coup ? le nom du paquet source suivi du numéro de version ? Genre gnelib-0.7-examples (qui dépendrait de libgnelib0-dev et libgnelibdata2-dev par exemple) ?

À mon avis, ça dépend de :
1/ la taille des exemples
2/ si les exemples ne s'appliquent qu'à une version spécifique de la lib

Si la taille des exemples est faible (qq Ko), c'est du travail pour rien, tu peux très bien les caser dans le -dev (/usr/share/doc/<ta lib>/examples). Et dans le cas où tu choisisses de séparer, si les exemples ne s'appliquent qu'à une version particulière de la lib, tu peux créer un paquet spécial (gnelib-0.7-examples par exemple).

Franchement, si upstream n'a pas compris qu'il doit utiliser des sonames et filer autre chose que des trucs statiques, alors tu t'embêtes pour rien...

16ar · Le 11/09/2007, à 13:28

mr_pouit a écrit :

16ar a écrit :
- j'ai téléchargé les sources de HawkNL, et le paquet source je l'ai nommé hawknl, jusque la, pas de soucis.
- Le paquet hawknl ne génère qu'une seule bibliotheque .so nommé libNL.so.1.6.8 (avec le soname = NL.so.1.6). J'imagine que je dois renommer le soname libNL.so.1.6, car la notation purement NL.so.1.6 ne fonctionnerait pas de base si la library name serait pareille (/usr/lib/NL.so.1.6), il faut un prefixe lib, non ?
le soname = les chiffres seulement.
Et le nom de la lib est correct, sauf si une lib avec le même nom existe déjà dans debian.

ok, donc le soname = 1.6
en tout cas, avec un objdump -p /usr/lib/libNL.so.1.6 | grep SONAME, j'obtiens SONAME NL.so.1.6
Au total, le makefile du projet, il génère dans /usr/lib/ :
libNL.a
libNL.so.1.6.8
Puis des liens vers cette bibliotheque
NL.so.1.6
libNL.so.1.6
libNL.so.1
libNL.so

Ce que j'aimerais savoir, c'est : est ce que un libname sans un prefix lib... est valable sous GNU/Linux ? Il me semble que gcc/ld et tout le systeme de bibliotheque dynamique cherche des noms du type : libNOMDELALIB.extension
non ?
Du coup, d'apres moi, le NL.so.1.6 ca me semble une erreur, et du coup, le resultat du objdump aussi
Ainsi, il faudrait que upstream vire toute les references a NL.so.1.6 et ne laisser que les references a libNL.1.6, non ?
(apres le conflit de nom avec un autre lib, c un autre probleme )

mr_pouit a écrit :

- HawkNL génère donc libNL.so.1.6. Seulement, il existe deja un paquet libnl1 (et un libnl1-pre6 d'ailleurs, a peu de chose pres ... lol) Que dois je faire contacter la ml debian/ubuntu pour savoir si je dois renommer la librairie en libHawkNL.so.1.6 ? pour avoir un paquet libhawknl1.6 ?
donc dans ce cas, il faudrait qu'upstream renomme sa lib.

Ok, il faut donc que je le contacte
Par contre, c pas un vrai conflit de nom de lib.
libnl1-pre6 donne : libnl.so
libnl1.6 donne : libNL.so
Par contre, il y'aurait un risque de conflit de paquet par la suite vu que le nom de paquet n'est qu'en minuscule

mr_pouit a écrit :

A moins que ca ne soit le library name a changer en NL.so.1.6, avec les liens symboliques du type : NL.so.1 et NL.so, non ?
-- evidemment si je change le soname, il faut que j'en informe upstream j'imagine ? (mais je vais d'abord vérifier comment il a géré ca dans sa version beta 1.7)
Encore une fois, c'est pas à toi de faire ça, c'est à upstream (tu peux très bien tout patcher dans ton paquet, mais bon...).
Et le soname me paraît faux : le soname ne doit pas être relié à la version du logiciel. Là on a le soname 1:6:8 pour la version 1.6.8 de hawknl, ça ne me semble pas correct (cf. http://www.gnu.org/software/libtool/manual.html#Updating-version-info)

En effet, le soname semble mauvais, mais a priori, l'ABI est cassé a chaque nouvelle release, du coup, le soname ne semble pas si aberrant

mr_pouit a écrit :

- autre souci, GNElib est une surcouche a HawkNL, et dans la config de base, il ne génère qu'une archive libgne.a
D'autre part dans le readme.linux, il est indiqué de copier le fichier include/libgnelib.h et lib/libgnelib.a.
Or l'archive générée n'a pas ce nom la. Je suis le README ? ou je garde ce que fait le make ?
Pour le moment, j'ai un paquet libgnelib0 qui n'a pratiquement rien (a part que j'ai quand meme généré un libgnelib.so.0 au cas ou) et un libgnelib0-dev qui contient un libgnelib.a.
Dans le cas d'un .so, il faut 1 paquet du nom du soname, mais quand c'est une librairie statique, on choisit comment ?
Et normalement, il vaut mieux un .so qu'un .a, donc je dois fournir un patch pour générer le .so, c'est ca ?
[EDIT] Dans le svn, le makefile génère un libgnelib.a . Donc c'est bon pour le nom du paquet actuel.
C'est pas génial les libs statiques.
C'est vraiment à upstream de faire ça, pas à toi.

Trop tard ... ^^ C'est sur REVU

mr_pouit a écrit :

- Derniere question : j'ai des exemples de code pour GNElib. Ou dois je les placer ?
J'ai pensé a un paquet : libgnelib0-examples. Mais est ce cela ? ou plutot le nom du paquet source + -examples ? (genre gnelib-examples). Vu qu'a priori les sources sont liées au biblio de dev, je pense qu'utiliser le nom du paquet de bibliotheque n'est pas si bete. Seulement, gnelib ne génère qu'une bibliotheque. Si elle en générait plusieurs, les sources d'exemples dépendraient des differentes bibliotheques de developpement et 1 seul nom de bibliotheque ne conviendrait pas. Il faudrait utiliser quoi du coup ? le nom du paquet source suivi du numéro de version ? Genre gnelib-0.7-examples (qui dépendrait de libgnelib0-dev et libgnelibdata2-dev par exemple) ?
À mon avis, ça dépend de :
1/ la taille des exemples
2/ si les exemples ne s'appliquent qu'à une version spécifique de la lib
Si la taille des exemples est faible (qq Ko), c'est du travail pour rien, tu peux très bien les caser dans le -dev (/usr/share/doc/<ta lib>/examples). Et dans le cas où tu choisisses de séparer, si les exemples ne s'appliquent qu'à une version particulière de la lib, tu peux créer un paquet spécial (gnelib-0.7-examples par exemple).

Franchement, si upstream n'a pas compris qu'il doit utiliser des sonames et filer autre chose que des trucs statiques, alors tu t'embêtes pour rien...

En fait, ma question, c'était surtout
Pour un paquet gnelib-0.7-examples par exemple, je met les documents dans quoi ?
/usr/share/doc/<nom du paquet debian.deb>/examples
ou bien
/usr/share/doc/<nom du paquet debian source>/examples ??

(donc pour l'example
/usr/share/doc/gnelib-0.7-examples/doc/examples
ou
/usr/share/doc/gnelib/doc/examples
?)

Et si je mets finalement les sources d'examples dans le -dev, je met ca ou ?
/usr/share/doc/libgnelib0-dev/doc/examples
ou
/usr/share/doc/libgnelib0/doc/examples
ou
/usr/share/doc/gnelib/doc/examples

Voila

En fait, je n'ai toujours pas contacté upstream... J'attendais d'avoir des eclaircissements meilleurs avant de leur demander des choses.
Au tout début, je croyais que le soname se basait sur la version du source, j'aurai eu l'air bien fin de lui demander 2 semaines plus tard de le changer en numéro different...

Et puis, HawkNL + GNELib ne sont que des dépendances de Delta3D. Or c'est ce dernier projet qui m'intéresse le plus. Donc je suis en relation surtout avec eux, pas du tout avec les autres upstream pour le moment (mais ca va venir pour qu'il aient des sources mieux Mais GNELib est passé a cmake entre temps, ca devrait plus le faire )

Ensuite, derniere question, le paquet delta3d va générer une dizaine de .so (1 par namespace C++ en fait). Normalement, il faut que je créé 1 paquet deb par .so, vrai ?
Seulement, le paquet openscenegraph (qui lui aussi génére 1 .so par namespace) contient tous les .so en 1 seul paquet.
Comme indiqué au 8.1 du Debian Policy : http://www.debian.org/doc/debian-policy/ch-sharedlibs.html, ca semble bon. Et du coup, tous les soname ont la meme version. C'est bien cela ? ou j'ai tout compris de travers ?
A priori c'est cela vu que libopenscenegraph4 fournit toutes les libs avec le soname de 4 (libosg.so.4, libosgDB.so.4, libosgChar.so.4 ...). Mais je demande validation avant de conseiller une betise
Seulement, le soname va changer quand bien meme l'ABI n'aura pas changé, c'est ca ?

Désolé pour la longueur, mais on arrive au bout (j'ai posté hawknl et gnelib sur revu (meme si gnelib dépend de hawknl...). On verra bien ce qu'on me dira la bas

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 23/02/2007, à 19:39

Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#2 Le 23/02/2007, à 21:49

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#3 Le 24/02/2007, à 20:59

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#4 Le 24/02/2007, à 22:13

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#5 Le 24/02/2007, à 22:34

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#6 Le 24/02/2007, à 23:23

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#7 Le 25/02/2007, à 00:09

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#8 Le 25/02/2007, à 02:35

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#9 Le 08/08/2007, à 15:04

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#10 Le 08/08/2007, à 18:24

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#11 Le 10/08/2007, à 20:14

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#12 Le 10/08/2007, à 20:54

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#13 Le 22/08/2007, à 16:33

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#14 Le 22/08/2007, à 21:11

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#15 Le 23/08/2007, à 10:58

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#16 Le 27/08/2007, à 14:02

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#17 Le 05/09/2007, à 17:50

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#18 Le 10/09/2007, à 22:14

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

#19 Le 11/09/2007, à 13:28

Re : Compilation de paquet debian à partir de sources (delta3d, HawkNL)

Pied de page des forums