Bonjour tout le monde,
Bonjour Riri,
> Test effectué, et ça ne marche pas, voici ce que me retourne Ncooker:
> The following errors occured :
> bin/bash: this dependent file was not found in the package database
> bin/sh: this dependent file was not found in the package database
> lib//toolsld-linux.so.2: this dependent file was not found in the package
> database
> lib/libCNS.so: this dependent file was not found in the package database
> lib/libGB.so: this dependent file was not found in the package database
> lib/libISOIR165.so: this dependent file was not found in the package database
> lib/libJIS.so: this dependent file was not found in the package database
> lib/libJISX0213.so: this dependent file was not found in the package database
> lib/libKSC.so: this dependent file was not found in the package database
> lib/statically: this dependent file was not found in the package database
> usr/bin/perl: this dependent file was not found in the package database
Hummm... C'est pas gagné...
> Pour bash/sh/perl, ma foi, je dirais que dans l'ordre normal des
> choses (pour un autre paquet), ces dépendances devraient être
> présentes (car la glibc fournit des scripts qui ont besoin de ces
> interpréteurs). Par contre, la glibc étant l'un des tout premiers
> paquets installé, il doit pouvoir s'installer sans dépendance
> (problème de l'oeuf et de la poule), d'où la nécessité des surcharges
> telles qu'on en a parlé.
Tout à fait d'accord.
> pour lib//toolsld-linux.so.2, je ne vois pas comment Ncooker a pu
> arriver à ce résultat :-) Il semble qu'il y ait oune picolo bug in the
> marmite :). Il existe bien une dépendance sur le chargeur
> /tools/lib/ld-linux.so.2 mais qui sera modifiée manuellement (par
> Ndkm) avant d'installer les autres paquets (le fameux ajustement).
> Lors de la création du paquet glibc, il faut donc que cette dépendance
> n'existe pas. Le problème peut être résolu en évinçant ld-linux.so.2
> de la liste des dépendances, car comme il s'agit du chargeur de
> bibliothèques partagées, elle est à fortiori indispensable à tout
> programme/bibliothèque ayant des dépendances. Par ailleurs, suivant la
> plateforme, ce nom peut changer (en ld.so par exemple), ce qui
> dissuade la présence de ce nom en dur, si jamais ça aurait tenté
> quelqu'un :-)
Heu... ben c'était justement en dur dans Ncooker (ce que j'ai récupéré de
Ncooker 2).
J'ai fait un commit sur le dépôt SVN afin :
- de gérer n'importe quel chemin du chargeur de librairie partagée (/lib,
/tools/lib, ...)
- de gérer différents noms du chargeur de librairie partagée
(ld-linux.conf.so.2, ld-linux.conf.so, ld.so, ...).
Est-ce que cela améliore les choses ?
> Nous avons ensuite les libMACHIN.so qui ne sont pas dans lib mais dans
> lib/glibc et sont fournis par la glibc. Il y a un problème au niveau
> Ncooker là.
Oui, ça doit être un problème Ncooker. Pourrais-tu me donner le résultat des
deux commandes suivantes ?
find "" -type f \
| xargs file 2>/dev/null \
| grep "ELF .* executable" \
| grep "dynamically linked" \
| cut -f1 -d: \
| xargs ldd 2>/dev/null
find "" -type f \
| xargs file 2>/dev/null \
| grep "ELF .* shared object" \
| cut -f1 -d: \
| xargs ldd 2>/dev/null
> Et enfin, il y a le fameux lib/statically qui n'existe pas :-). Je
> n'ai pas encore retrouvé d'où ça sort, mais étant dans lib, ça doit
> être lors des ldd sur les bibliothèques (situées dans lib/glibc)
Ca a l'air aussi mystérieux que le fichier "linux-gate.so". Je peux modifier
Ncooker pour ignorer cette dépendance si ce fichier n'existe pas réellement sur
le système (cas d'une pseudo-dépendance).
> Pour conclure, on a encore du taf :-)
Clairement... :)
@+
--
JulienL
_________________________________________________________________
Retrouvez Windows Live Messenger sur votre mobile !
http://www.messengersurvotremobile.com
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
