2016-10-12 3 views
1

J'essaye de construire zlib avec le jeu d'outils Tizen. Dans le cadre du processus de construction, les fichiers sources sont censés être compilés dans des objets avec arm-linux-gnu-eabi-gcc -c, puis combinés dans une archive avec libtool, mais libtool échoue et se plaint que chacun des fichiers .o lui a été transmis is not an object file (not allowed in a library). Après inspection, je trouve que arm-linux-gnu-eabi-gcc -c génère des fichiers ELF plutôt que des fichiers objets, quelque chose que je n'avais jamais vu auparavant. Lorsque je passe -c -v au compilateur, je peux voir que l'éditeur de liens n'est pas appelé. Alors pourquoi le format ELF?Tizen gcc assembler générant des ELF au lieu de fichiers objets - impossible de créer une bibliothèque statique

J'ai ensuite essayé d'appeler arm-linux-gnu-eabi-gcc -S suivi de arm-linux-gnu-eabi-as, et découvert que l'assembleur génère lui-même des fichiers ELF.

Voici un exemple:

% echo "int main(void) { return 0; }" > main.c 
% arm-linux-gnueabi-gcc main.c -S -o main.s 
% arm-linux-gnueabi-as main.s -o main.o 
% file main.o 
main.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped 

Le jeu d'outils Tizen comprend quatre compilateurs ({i386, bras} et {4.6,4.9}). Tous les quatre se comportent de la même manière.

Au moins ce arm-linux-gnueabi-gcc est cohérent, parce que je peux lui passer un certain nombre de fichiers ELF .o et il semble les lier correctement. Mais j'ai encore besoin de pouvoir générer de vrais fichiers objets afin qu'ils puissent être archivés dans une bibliothèque statique avec libtool. Aucune suggestion?

Répondre

1

est la génération de fichiers ELF plutôt que des fichiers d'objet,

Vous êtes très confus: ELF et fichiers objet ne sont pas exclusifs, et sur Linux tous fichiers objets sont ELF. En d'autres termes, cela fonctionne comme prévu.

fichiers ELF peuvent avoir le type différent: ET_REL (repositionnable objet fichiers), ET_DYN (bibliothèques partagées) et ET_EXEC (executables).

Je dois encore être en mesure de générer de véritables fichiers objets afin qu'ils puissent être archivés dans une bibliothèque statique avec libtool

Le problème est probable que libtool ne reconnaît pas non natif ELF.o fichiers comme quelque chose qu'il peut mettre dans une bibliothèque d'archives.

En général, libtool est presque toujours la mauvaise solution au problème, quel que soit le problème. Son stated goal est de "cacher la complexité de l'utilisation de bibliothèques partagées derrière une interface cohérente et portable". Dans mon expérience, il échoue spectaculairement à atteindre cet objectif sur toutes les plates-formes.

Certes, si vous juste voulez mettre un tas de fichiers .o dans une bibliothèque d'archives, la bonne façon de le faire est d'utiliser simplement *-linux-gnueabi-ar qui ne devrait avoir aucun problème.

+0

Pensées intéressantes sur 'libtool'.Je ne l'ai pas vraiment utilisé moi-même, mais de nombreux projets semblent l'utiliser, et je l'utilise ici simplement parce que "zlib" le veut. –

+0

Je pense que je savais que les objets étaient des fichiers 'ELF', mais l'avait oublié dans le coup par coup avec le processus de construction. Merci pour l'explication. J'ai fini par résoudre le problème en m'assurant que la variable d'environnement 'AR' était correctement définie, afin que' libtool' puisse invoquer le 'ar' non natif auquel vous avez fait référence. –