Que signifie Linux obj ?

linux obj représente ".o" sous Linux, qui est le fichier cible, qui est équivalent au fichier ".obj" sous Windows ; obj stocke le code et les données compilés, et a un nom, donc lors de la connexion Parfois des problèmes non résolus des symboles externes apparaissent.

L'environnement d'exploitation de ce tutoriel : système linux5.9.8, ordinateur Dell G3.

Que signifie Linux obj ?

Une brève analyse des fichiers .a, .so et .o sous Linux

Avant-propos

Lorsque nous installons le code source sur la plateforme Linux, nous rencontrons souvent des fichiers .so et .o informations de sortie. D'une manière générale, il suffit de jeter un coup d'œil aux informations de sortie de ces fichiers et n'avons pas besoin de les explorer en profondeur. Mais si nous devons écrire le code source nous-mêmes et le compiler manuellement, nous devons avoir une compréhension approfondie de ces informations.

Explication du fichier

Sous Linux, ces fichiers .so, .o et .a correspondent en fait aux fichiers obj, lib, dll, exe et autres fichiers sous Windows. Avant d'expliquer ces fichiers sous Linux, parlons d'abord du rôle de ces fichiers sous Windows.

La relation entre obj, lib, dll et exe sous Windows

exe est le suffixe du programme exécutable que nous connaissons habituellement, tandis que obj, lib et dll sont les fichiers clés qui constituent le programme en cours d'exécution. lib correspond à dll. lib est le fichier bibliothèque de la bibliothèque de liens statiques et dll est le fichier bibliothèque de la bibliothèque de liens dynamiques.

Ce qu'on appelle statique signifie que lorsque vous créez un lien, extrayez les éléments nécessaires et organisez-les dans votre fichier exe. Lorsque vous exécuterez votre exe à l'avenir, vous n'aurez plus besoin de lib. Ce qu'on appelle dynamique signifie que lorsque l'exe s'exécute, cela dépend des fonctions fournies dans la dll. Sans cette dll, votre exe ne peut pas s'exécuter.

lib, dll et exe sont tous considérés comme les fichiers cibles finaux et le produit final. Et c/c++ appartient au code source. La transition entre le code source et le fichier cible final est le code intermédiaire obj. En fait, la raison pour laquelle le code intermédiaire est nécessaire est que vous ne pouvez pas obtenir le fichier cible en même temps.

Par exemple, un exe nécessite la génération de nombreux fichiers cpp. Le compilateur ne peut compiler qu'un seul fichier cpp à la fois. De cette façon, une fois que le compilateur aura compilé un cpp, il sera compilé en obj. Lorsque tous les cpp nécessaires seront compilés en obj, ils seront unifiés et liés dans l'exe requis. Il faut dire que l'absence de tout obj entraînera. le lien exe échoue.

obj stocke le code et les données compilés et porte des noms, de sorte que des problèmes de symboles externes non résolus surviennent parfois lors de la connexion. Lorsqu'il est connecté à un exe, il n'y a pas de notion de nom, seulement une adresse. lib est une combinaison d'un tas d'obj.

En théorie, vous pouvez connecter des fichiers obj pour référencer d'autres projets (vous pouvez considérer un fichier obj comme équivalent au fichier cpp qui le compile et le génère. Vous pouvez référencer obj pour remplacer cpp, ou ajouter cpp pour remplacer obj), mais dans la pratique, lib est généralement utilisé pour obtenir une référence mutuelle entre les projets.

Le compilateur reliera par défaut certaines bibliothèques couramment utilisées et vous devrez en spécifier d'autres par vous-même.

La différence entre lib et dll

lib est nécessaire lors de la compilation, et dll est nécessaire lors de l'exécution. Si vous souhaitez terminer la compilation du code source, lib suffit. Si vous souhaitez exécuter des programmes liés dynamiquement, une DLL suffit. Lors des phases de développement et de débogage, il est bien entendu préférable d’avoir les deux.

Les programmes de bibliothèque dynamique généraux incluent des fichiers lib et des fichiers dll. Le fichier lib doit être connecté à l'application lors de la compilation, tandis que le fichier dll n'est appelé que lors de l'exécution. S'il existe un fichier dll, le fichier lib correspondant contient généralement des informations d'index et l'implémentation spécifique se trouve dans le fichier dll. S'il n'y a qu'un fichier lib, alors ce fichier lib est compilé de manière statique et l'index et l'implémentation s'y trouvent.

Les fichiers lib compilés statiques présentent des avantages : il n'est pas nécessaire d'installer des bibliothèques dynamiques lors de leur installation auprès des utilisateurs. Mais il y a aussi des inconvénients, à savoir que l'application est relativement volumineuse et que la flexibilité de la bibliothèque dynamique est perdue. Lors de la mise à niveau de la version, une nouvelle application doit être publiée en même temps.

Dans le cas d'une bibliothèque dynamique, il y a deux fichiers, l'un est le fichier de la bibliothèque d'importation (.LIB) (en fait c'est aussi une bibliothèque statique, mais lors de la liaison, vous ne pouvez lier que l'entrée de la fonction dans la dll à l'exe, et contrairement à une véritable bibliothèque de liens statiques qui relie réellement le corps de la fonction à l'exe, la liaison dynamique via lib est en fait implémentée à l'aide de la liaison statique). L'un est un fichier dll. Le fichier de bibliothèque importé contient le nom et la fonction du. fonction exportée par la dll. Emplacement, la dll contient les fonctions et les données réelles. L'application utilise le fichier LIB pour créer un lien vers le fichier dll qu'elle doit utiliser. Les fonctions et les données de la bibliothèque ne sont pas copiées dans le fichier exécutable.

Ainsi, dans le fichier exécutable de l'application, ce qui est stocké n'est pas le code de la fonction appelée, mais l'adresse mémoire de la fonction à appeler dans la dll. De cette façon, lorsqu'une ou plusieurs applications sont en cours d'exécution, le programme. Le code et la fonction appelée sont stockés. Les codes de fonction sont chaînés, économisant ainsi les ressources mémoire. Comme le montre la description ci-dessus, les fichiers dll et .LIB doivent être distribués avec l'application, sinon l'application générera des erreurs.

Les fonctions des dll sont divisées en deux types :

les fonctions exportées des dll, qui peuvent être appelées par les applications ;

les fonctions internes des dll, qui ne peuvent être utilisées que dans les programmes dll, et les applications ne peuvent pas les appeler

.o, . a sous Linux La différence entre les fichiers .so et .o est le fichier cible, qui est équivalent au fichier .obj sous Windows.

.so est une bibliothèque partagée, un objet partagé, utilisé pour la connexion dynamique, équivalent à une dll sous Windows, et un fichier exécutable sous Linux.

.a est une bibliothèque statique. Pour parler franchement, il s'agit d'un ensemble de .o rassemblés pour une connexion statique. L'effet est le même que .o.

Bibliothèque de fonctions statiques

Caractéristiques : Il s'agit en fait d'une collection de fichiers cibles ordinaires simples, qui sont ajoutés au programme cible avant l'exécution du programme.

Avantages : Compatible avec certains programmes précédents ; description simple ; permet aux programmeurs de lier des programmes sans recompiler le code, ce qui signifie qu'aucune prise en charge de fonctions externes n'est requise, économisant ainsi le temps de recompilation du code (cet avantage n'est actuellement pas évident) ; les développeurs peuvent également garder le code source secret.

Le nom de ce type de bibliothèque est généralement libxxx.a. Le fichier compilé à l'aide d'une bibliothèque de fonctions statiques est relativement volumineux, car toutes les données de l'ensemble de la bibliothèque de fonctions seront intégrées dans le code cible.

Inconvénients : Si la bibliothèque de fonctions statiques change, votre programme doit être recompilé.

Bibliothèque de fonctions partagées

La bibliothèque de fonctions partagées est chargée lorsque le programme exécutable démarre, et les fonctions de la bibliothèque de fonctions partagées peuvent être automatiquement chargées lorsque tous les programmes sont réexécutés. Par rapport aux bibliothèques de fonctions statiques, les bibliothèques de fonctions partagées ne sont pas compilées dans le code cible lors de la compilation.

La fonction correspondante dans la bibliothèque de fonctions partagée n'est appelée que lorsque le programme exécute la fonction correspondante, le fichier exécutable généré par la bibliothèque de fonctions partagée est donc relativement petit. Puisque la bibliothèque de fonctions partagée n'est pas intégrée à votre programme, elle est utilisée. lorsque le programme est en cours d'exécution. Appliquez et appelez dynamiquement, la bibliothèque correspondante doit donc être fournie dans l'environnement d'exécution du programme.

Les modifications dans la bibliothèque de fonctions partagées n'affectent pas votre programme, il est donc plus pratique de mettre à niveau la fonction partagée. bibliothèque

Recommandations associées : "

Tutoriel vidéo Linux

》

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!