J'utilise un système DEV où je dois spécifier le nom de la lib lors de l'accès à une fonction à l'intérieur.
J'ai utilisé des fonctions comme Open () avant et d'une manière ou d'une autre, elles sont découvertes sur libc.so.
Maintenant, je veux utiliser lstat (), mais il semble que celui-ci n'est pas en libc. Malheureusement, les pages de l'homme que j'ai examinées ne documentent pas l'emplacement des fonctions.
Donc, deux questions:
6 Réponses :
du MANPAGE (homme lstat):
OP veut savoir quelle bibliothèque les fonctions finissent par être stockées dans le fichier d'en-tête.
Ceci est un moyen de le faire:
tomislav@malik:~$ cd /usr/lib tomislav@malik:/usr/lib$ grep "lstat()" * Binary file libperl.so.5.10 matches Binary file libperl.so.5.10.0 matches tomislav@malik:/usr/lib$
liberl? Cela ne peut pas avoir raison. Utilisez la commande 'nm' à la place. Tels que nm lib * .so * | grep lstat .
Oui, le grep montre également importations , je crois, donc le mauvais résultat de libperl.
Libpert Correspond parce qu'il contient la chaîne lstat () , qui est une fonction Perl implémentée ici. Cela a peu à voir avec le Syscall sous-jacent.
Les pages de l'homme indiquent généralement quelle bibliothèque ils sont dans. lstat est en libc et libc est lié par défaut. Vous n'avez rien à faire pour utiliser lstat en plus d'inclure le fichier d'en-tête pour celui-ci #include
Je pense que j'ai clairement souligné que ce n'est pas à propos de C mais à propos d'un développement envers lequel j'ai besoin de spécifier explicitement la lib.
Néanmoins, c'est dans Libc, alors lien avec Libc. Si tel est un environnement qui a peu à voir avec ce qui est normalement trouvé sur une machine Linux, vous devez nous dire quel type d'environnement cela est. Il n'y a pas de moyen de savoir où savoir où les fonctions résident en plus de sa documentation - ce qui manque parfois.
NOS - La seule raison pour laquelle je ne pouvais pas le trouver dans Libc, c'était qu'il n'était pas déclaré là-bas, comme vous l'avez souligné ci-dessus. J'ai résolu-le maintenant, merci.
Construisez une simple testeuse en C, compilez-la et exécutez «LDD -R» dessus pour vérifier ce que les libs sont chargés. Si vous n'obtenez pas lstat () en C, alors vous avez un problème sur votre développement env. Ou cet env Dates de retour avant l'âge des symboles: -)
Bonne idée. Dans ce cas, le problème était en réalité qu'il n'y a vraiment pas de lstat dans la lib, mais seulement __lxstat. Ce qui pourrait être vu dans les en-têtes, cependant.
Cette idée n'est pas trop bonne s'il existe une fonction de bibliothèque inconnue et non liée à par défaut. Il n'y aura pas de binaire pour exécuter ldd sur avant que le nom de la bibliothèque soit ajouté à la liaison binaire. PS: il y a aussi ld_debug = tout ./binary pour voir le processus de liaison réelle; LD.SO montrera quels symboles sont posés et où il essaie de les trouver.
Lorsque je compile des applications Windows sur Linux, si j'ai un problème avec la liaison, j'ai tendance à utiliser ce script que j'ai nommé Mingw-Findin. Un script similaire pourrait être utilisé pour la compilation de Linux régulière, juste au lieu d'utiliser l'alternative MINGW, utilisez NM régulier et au lieu de regarder dans le répertoire préfixé de la compilation croisée, regardez / usr / lib. Pour utiliser ce script, j'exécute
./ MINGW-FINUTIN Nomoffuncunction P>
Voici le code: P>
#!/bin/sh
liblist=` ls /usr/x86_64-w64-mingw32/lib `
for i in $liblist
do
if x86_64-w64-mingw32-nm /usr/x86_64-w64-mingw32/lib/$i | grep -q $1; then
echo $i
x86_64-w64-mingw32-nm /usr/x86_64-w64-mingw32/lib/$i | grep $1
fi
done
Ou nm avec -d drapeau? Sur Linux il y a aussi / lib; Nous devrions donc vérifier /etc/ld.so.conf et /etc/ld.so.conf.d/* pour les chemins de recherche des bibliothèques.
Essayez ceci:
$ cat ./foobar.c
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
int main(void)
{
struct stat buf;
return lstat(".", &buf);
}
$ LD_DEBUG=bindings ./foobar 2>&1 | grep stat
31000: binding file ./foobar [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: \
normal symbol `__lxstat' [GLIBC_2.2.5]
Impossible d'utiliser la commande 'nm' pour ceci:
nm lib * .so * | grep lstat . Non testé d'où le commentaire, pas la réponse.lstat n'est pas présent comme un symbole dans Libc, il semble être appelé __lxstat, et c'est probablement résolu au moment de la liaison
Malheureusement, tout ce que je reçois, c'est une longue liste de "NM: libxxx.sp.n: aucun symbole". Impair. Peut-être que quelque chose est endommagé dans mon système.
NOS - __LXSTAT est en effet là, mais il ne semble pas fonctionner - il continue de retourner -1. Je suppose que c'est parce qu'il a des paramètres plus ou différents. (Mise à jour) En effet - j'aurais dû vérifier d'abord le fichier d'en-tête. Il est déclaré là-bas.
Pour les objets dynamiques, tels qu'une bibliothèque partagée, l'option
-d est nécessaire avecnm pour afficher les symboles dynamiques plutôt que les symboles normaux.