Discussion :

[Kalith]

Bonjour à tous!

Voici mon problème :

• Projet principal, nécessite la lib "ma_lib.a"
• Ma lib, nécessite la lib "autre_lib.a"

Si je veux compiler le projet principal, je dois le linker avec "ma_lib.a", ce qui est tout à fait normal et compréhensible, mais aussi avec "autre_lib.a", dont il ne dépend pas directement.
J'aimerai éviter ça, et inclure directement "autre_lib.a" dans "ma_lib.a".

J'y suis parvenu avec une méthode un peu bourrin : décompresser les deux lib, et recompresser tous les *.o dans "ma_lib.a".
Ca fonctionne, mais je voulais savoir s'il existait une commande de LD ou AR qui pourrait me faire ça plus proprement ?

Je sais le faire avec Visual C++ (dans les options du Librarian), mais pas avec G++ (Code::Blocks).

(pour info, "ma_lib.a" c'est OIS, une bibliothèque d'input, et "autre_lib.a" c'est DirectInput)

[koala01]

Si je veux compiler le projet principal, je dois le linker avec "ma_lib.a", ce qui est tout à fait normal et compréhensible, mais aussi avec "autre_lib.a", dont il ne dépend pas directement.
J'aimerai éviter ça, et inclure directement "autre_lib.a" dans "ma_lib.a".

Oui, c'est embêtant, mais c'est comme cela

Il faut te dire que, de toutes manières, la dépendance reste présente au niveau des fichiers d'en-tête:

Si, tu l'as surement fait à une occasion ou une autre dans ton projet (parce que tu n'avais pas le choix, tres certainement ) un des fichier d'en-tête "publique" propre de ma_lib inclus un fichier d'en-tête de autre_lib, et que tu essaye de compiler ma_lib sur une machine qui ne dispose pas de autre_lib... le compilateur t'enverra paitre parce qu'il ne trouvera pas le fichier de autre_lib en question

J'y suis parvenu avec une méthode un peu bourrin : décompresser les deux lib, et recompresser tous les *.o dans "ma_lib.a".

C'est, effectivement, très bourrin comme méthode, et à éviter autant que possible

Ca fonctionne,

sur ta machine, oui, parce que tu dispose des fichiers d'en-têtes de autre_lib...

Mais, si tu veux donner à ton voisin ta bibliothèque et qu'il ne dispose pas, au minimum, des fichiers d'en-tête de l'autre bibliothèque... ca va coincer (à moins qu'il n'y ait aucun fichier d'en-tête de l'autre bibliothèque qui ne soit inclu dans ceux de la tienne... ce qui est loin d'être gagné)

mais je voulais savoir s'il existait une commande de LD ou AR qui pourrait me faire ça plus proprement ?

Comme j'essaye de te le faire comprendre, cela n'aurait pas de sens:

Cela en a d'autant moins que les chemins d'accès aux fichiers (d'en-tête et *.a) bibliothèques sont personnalisables:

Sur une machine donnée, les fichiers d'en-tête peuvent se trouver dans le dossier / un sous dossier include du compilateur, alors qu'il peuvent se trouver dans une dossier tout à fait différent sur une autre machine, et il en va de même pour les fichiers .a ... Surtout si l'utilisateur en question n'a pas utilisé un installateur automatique mais a décidé de compiler lui-même la bibliothèque en question.

A titre d'exemple (strictement personnel), j'utilise actuellement sous windows une version de Gcc capable de fournir des binaire 32 et 64 bits, dont le chemin de base est placé en C:\MinGW.

et j'ai une arboresence proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
C:
 |    MinGW // chemin de base du compilo
 |    |   bin // chemin des exécutables (ajouté à la varaible PATH )
 |    |   include // fichiers d'en-tête requis pour la compilation de Gcc
 |    |   lib // fichiers *.a requis pour la compilation de Gcc
 |    |   dll32 // dll's en version 32 bits (ajouté à la variable PATH)
 |    |   dll64 // dll's en version 64 bits (ajouté à la variable PATH)
 |    |   x86_64-w64-mingw32 // correspond à l'hote
 |    |   |    include // en-tete runtime (automatique pour Gcc)
 |    |   |    lib32  // *.a "32 bits" du runtime (automatique pour ld)
 |    |   |    lib64  // *.a "64 bits" du runtime (automatique pour ld)
 |    MesLibs
 |    |    lib1
 |    |    |    include
 |    |    |    lib
 |    |    lib2
 |    |    |    include
 |    |    |    lib
 |    |    ...

Le tout, sans oublier boost ou Qt qui ont toutes les deux droit à un dossier dédié.

Si je veux utiliser la bibliothèque lib1, lib2, ... libx, Qt ou boost, je dois, de toutes manières, explicitement indiquer à Gcc dans quel dosser aller chercher les en-tête correspondant, et indiquer à ld le dossier dans lequel il trouvera le *.a qui lui faut.

Tu remarque que la dépendance avec le fichier de bibliothèque statique ne représente qu'une partie seulement de la dépendance de ton projet vis à vis de la bibliothèque...

Avant même d'arriver à vouloir la satisfaire, il faut que je la satisfasse au niveau de la compilation elle-même et donc au niveau des fichiers d'en-tête.

La solution *pourrait* être d'inclure l'ensemble des fichiers du projet "autre_lib" dans le projet "ma_lib", quitte à ce qu'il se trouve dans un sous dossier séparé.

Lorsque Ar se mettra au travail pour créer ton fichier ma_lib.a, il incluera automatiquement les fichiers objets de autre_lib.

Mais, et c'est très important, tu devra veiller à ce que les fichiers d'en-tête de autre_lib soient fournis avec les fichiers d'en-tête de ma_lib

(pour info, "ma_lib.a" c'est OIS, une bibliothèque d'input, et "autre_lib.a" c'est DirectInput)

Oulaa.. il faut donc être particulièrement prudent par rapport aux licences des bibliothèques utilisées vis à vis de la solution que je te propose...

Je crains fortement que DirectInput et OIS soient propriétaires, et que tu ne puisse donc pas agir comme je te le propose sans te mettre dans l'illégalité

[Kalith]

Wahou, heh bien merci pour toutes ces infos

Dans mon cas, "ma_lib" utilise "autre_lib" en interne uniquement : c'est une bibliothèque d'input extrêmement portable (j'en profite pour clarifier un truc au passage : je n'en suis pas l'auteur).
Aucun header de DirectInput n'apparait pour l'utilisateur de la lib.

Il reste une chose que je ne pige pas : on peut le faire avec Visual C++ (d'ailleurs le *.vcproj de OIS inclue bien DirectInput dans la *.lib).

[Laurent Gomila]

Voilà un exemple avec AR :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ar x autre_lib.a
ar rs ma_lib.a *.o
// ensuite il faut supprimer les fichiers *.o

[white_tentacle]

Il faut te dire que, de toutes manières, la dépendance reste présente au niveau des fichiers d'en-tête:

Si, tu l'as surement fait à une occasion ou une autre dans ton projet (parce que tu n'avais pas le choix, tres certainement ) un des fichier d'en-tête "publique" propre de ma_lib inclus un fichier d'en-tête de autre_lib, et que tu essaye de compiler ma_lib sur une machine qui ne dispose pas de autre_lib... le compilateur t'enverra paitre parce qu'il ne trouvera pas le fichier de autre_lib en question

Tout est dans le "si". Et d'ailleurs, Demeter te dirait volontiers que ce cas doit être à éviter, puisque ton client ne devrait pas savoir que tu utilises telle lib pour, mettons, encoder en base64, ce qui te permettra d'en changer comme tu le veux .