Ne peut pas trouver /lib/libc..6

Je suis à la cross-compilation d'une application, mais qui relie les coups avec une erreur qu'il

"impossible de trouver le répertoire /lib/libc..6".

La libc..6 qu'il devrait utiliser est celui qui est assis à /home/work/worldcom/filesys/lib/libc.so.6. Que dois-je mal ici?

linking libobj.so
arm-none-linux-gnueabi-g++ obj1.o obj2.o obj2.o  -o libobj.so -L/home/work/worldcom/filesys/usr -Wl,-O1 -Wl,-z,defs -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=both -L/home/work/worldcom/filesys -L/home/work/worldcom/filesys/lib -L/home/work/worldcom/filesys/usr/lib -lcurl -shared
/home/lishevita/armv5tel/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/home/lishevita/armv5tel/arm-2009q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find /lib/libc.so.6
collect2: ld returned 1 exit status<br />
make: *** [libobj.so] Error 1<br />

Mon makefile à la main (c'est à dire qui n'est pas généré par Autotools). Afin d'éviter une couverture "votre Makefile est brisé" voici quelques détails sur le fichier "makefile" qui pourrait aider à clarifier.

CROSS_COMPILE = arm-none-linux-gnueabi-  
SYSROOT = /home/work/worldcom/filesys/ 
DESTDIR = /home/work/worldcom/filesys/ 

RELEASE_CXXFLAGS = -Os  
DEBUG_CXXFLAGS = -O0 -gstabs  
PKGCONFIG=`env ROOT=/home/work/worldcom/filesys cross-pkg-config glib-2.0 libcurl --cflags`  

CC = $(CROSS_COMPILE)gcc  
CXX = $(CROSS_COMPILE)g++  
LD = $(CROSS_COMPILE)ld  
AR = $(CROSS_COMPILE)ar  

LDFLAGS = -Wl,-O1 -Wl,-z,defs -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=both -L$(SYSROOT) -L$(SYSROOT)lib -L$(SYSROOT)usr -L$(SYSROOT)usr/lib -lcurl  

libobj.so: $(LIBOBJ_OBJS)  
        @echo linking $@  
        $(CXX) $^ -o $@ $(LDFLAGS) -shared $(PKG_LIBS)

Bien sûr, il ya aussi une définition et une cible pour le LIBOBJ_OBJS mais ceux qui ne sont pas pertinents pour le problème.

Vous devriez jeter un oeil à la sortie de la <code>gcc-dumpspecs</code> - il peut avoir quelque chose là où il recherche la libc.

OriginalL'auteur lishevita | 2009-12-27

  1. 11

    Vous n'avez pas indiquer quelle version de gcc que vous utilisez, mais si c'est un assez récent, un (4.0.0 et au-dessus de moi pense), vous devriez essayer de le -sysroot drapeau à g++/ld. Point à $SYSROOT tel que défini dans votre Makefile.

    En supposant assez récente version de gcc, il va fonctionner.

    Espère que cette aide,
    Gilad

    Mon Héros!!! 🙂 C'est effectivement --sysroot sans "avec", mais on m'a orienté dans la bonne direction et il fonctionne. Maintenant j'ai un nouveau message d'erreur. De nouvelles erreurs sont bonnes. Cela signifie que je suis devant un problème et ont un tout nouveau défi pour induire une pression artérielle élevée! 🙂 Voici une nouvelle ligne dans mon Makefile: $(CXX) $^ -o $@ $(LDFLAGS) -partagé $(PKG_LIBS) --sysroot=$(SYSROOT)

    OriginalL'auteur gby

  2. 1

    Je suis juste allé à travers la même question; l'ajout de --sysroot=/rootfs/préfixe m'a aidé à obtenir plus près de la vraie question. Je l'ai résolu en installant paquet libstdc++-dev dans la cible.

    OriginalL'auteur Ester

  3. 0

    Avez-vous pas considéré que, éventuellement, la LIBPATH est définie et codée en dur à regarder pour le /lib/libc.so.6 et, par conséquent, la /lib chemin?

    Avez-vous essayé de définir la variable d'environnement comme celui-ci sur la ligne de commande, avant l'émission de la make lors de la compilation croisée:

    LIBPATH=/home/travail/worldcom/filesys/lib

    Dans votre cas, comme vous l'avez mentionné dans la balise cross-compilation", il peut être utile de supprimer les références aux /lib entièrement de la force de l'éditeur de liens pour regarder dans votre propre répertoire plutôt que de ne pas interférer avec la croix-processus de compilation.

    L'autre possibilité est que le compilateur gcc quand il a été construit pour votre environnement, de la configuration lors de la construction du compilateur à partir de la source, a été spécifié au point à la /lib chemin.

    Espère que cette aide,
    Meilleures salutations,
    Tom.

    Juste essayé <code>export LIBPATH=/home/travail/worldcom/filesys/lib</code>, et n'ai obtenu aucune joie. Peut-être que vous avez raison sur le compilateur gcc en cours de construction à point à l' /lib chemin, bien que cela semble bizarre. Je vais regarder dans que comme une source possible du problème. Merci, Lisha

    OriginalL'auteur t0mm13b

  4. -3

    Il semble que le makefile est brisé, parce que la libc..6 est supposé être situé dans le répertoire /lib/dossier (notez la barre oblique indiquant un chemin d'accès absolu! ). Cela semble être la question.

    Bien sûr, mais CE qui, dans le makefile peut être brisé? Vous pouvez voir à partir de ce que j'ai collé exactement ce qui est de la liaison, à droite? Et tous ceux -L est point à des endroits qui ne sont certainement pas /. Soooo... Il faut que ce soit quelque chose d'autre, je suis absent. Je vais ajouter plus d'informations sur ma question et voir si cela aide à clarifier tout...
    D'accord, je suppose que je n'étais pas assez clair ici.. :-). Il y a une énorme différence entre un nom de chemin d'accès comme /foo/bar et foo/bar. Le premier est toujours pointée /foo/bar /, comme on le voit à partir de la racine de votre système de fichiers, ce dernier dépend de votre répertoire de travail courant. Parce que le chemin d'accès dans le fichier makefile semble être absolu, c'est à dire à partir de la racine en cours, vos chemins de recherche ne sont même pas regardé et cherché la libc.. espérons que cela a aidé.
    Ce n'est pas le makefile qui est brisée, les chemins absolus sont contenues dans linker scripts. Ce n'est pas nécessairement mauvais, depuis la cross-compilation des linkers sont censés recherche sous un sysroot préfixe... mais il est très déroutant pour les messages d'erreur.

    OriginalL'auteur moritz