Renommez le fichier pdb avec les outils Visual Studio disponibles?

Question

Un logiciel tiers que nous construisons mais typiquement pas modifie de quelque façon que ce soit a un comportement étrange: Comme il est construit en tant que lib statique, le fichier PDB qu'il crée s'appelle vc.pdb et se trouve dans les logiciels ' dossier intermédiaire. Maintenant, il crée environ 12 de ces fichiers pdb, tous dans des dossiers différents, tous avec le même nom pour différentes bibliothèques et différentes configurations. Lorsque nous intégrons ce logiciel tiers dans notre code, nous obtenons l'avertissement LNK4099 parce que le chemin d'accès cédé pour le pdb n'est évidemment pas présent sur toutes les machines. En raison du fait que le logiciel tiers génère plusieurs fichiers .lib dans un répertoire de sortie, nous ne pouvons pas placer le fichier vc < ...> .pdb avec eux. Donc, je cherche un moyen de patcher les fichiers lib cuits dans le nom de pdb à quelque chose que j'ai sous mon contrôle. Est-ce que les outils de création de Visual Studio fournissent un moyen de le faire? Permettez-moi d'expliquer plus en détail ce que nous faisons: Nous avons décidé d'intégrer un tiers statique lib dans nos projets. Le projet lui-même est un paquet source. Un développeur ou le serveur de génération ou celui qui construit ce paquet source qui produit des bibliothèques liées statiquement appelées a.lib et b.lib dans diverses configurations de construction. Avec eux, la configuration visuelle par défaut du studio produit les fichiers vc110.pdb, car ils sont tous appelés de la même façon que VS les met automatiquement dans $ (IntDir). Donc, les fichiers pdb sont partout. Maintenant, nous validons ces binaires tiers à notre VCS pour le projet X donné. Celui qui utilise maintenant les bibliothèques statiques dans le projet X doit les lier dans le binaire final. C'est l'heure à laquelle le LNK4099 est généré car les fichiers pdb ne sont pas dans le VCS et ne sont pas disponibles sur cette machine.

Mais nous ne pouvons pas valider tous les fichiers vc110.pdb, car cela est inutile. Puisque le chemin qualifié complet est construit dans les bibliothèques statiques, aucun autre utilisateur ne pourra répliquer cela. Lors de la liaison, le chemin d'accès complet aux PDB ne peut pas être trouvé. Il recherche donc vc110.pdb à l'emplacement du fichier lib. Étant donné que le paquetage tiers a décidé de placer a.lib et b.lib dans le même répertoire, nous ne pourrons jamais placer correctement les fichiers pdb à moins que nous ne modifiions la construction du paquet tiers et ne renommions les fichiers pdb dans le vcxproj ou diviser la génération de libs pour être dans des répertoires différents (également dans le vcxproj).

C'est le point: Je voudrais pas modifier les fichiers de construction de la troisième partie à tout moment, je voudrais être en mesure d'utiliser un simple téléchargement frais de ce paquet tiers et le construire avec certains " simple "script de lot. Les résultats par défaut de ce paquet sont:

/Bin 
    /Debug 
     a.lib 
     b.lib 
    /Release 
     a.lib 
     b.lib 
/Temp 
    /A 
     /Debug 
      vc110.pdb 
     /Release 
      vc110.pdb 
    /B 
     /Debug 
      vc110.pdb 
     /Release 
      vc110.pdb 

Ce que je veux vraiment est de patcher les fichiers générés après la construction. Mon script «simple» par lots (ou autre) pourrait par exemple renommer les fichiers pdb en a.pdb et b.pdb, ce qui bien sûr ne suffirait pas car l'éditeur de liens chercherait toujours vc110.pdb car c'est le compilateur- au nom. C'est pourquoi je cherche un chemin (via des outils comme lib ou dumpbin, etc.) où je peux patcher mes libs générées au nouveau nom de pdb.

Comme ça:

$ magic /showPDB a.lib 
> D:\some_users_machine\unique_path\package\Temp\A\Debug.vc110.pdb 

$ magic /newPDB a.lib d:\path\a.pdb 
> New PDB name is d:\path\a.pdb 

Lorsque le consommateur lie alors mon patché a.lib il ne serait pas essayer de chercher a.pdb sur le chemin ci-dessus. Il serait bien sûr également ne pas être trouvé sur la plupart des machines, mais alors linker chercherait aussi un a.pdb à l'endroit où a.lib est situé et c'est là que je pourrais le placer maintenant pour tous.

Edit 2: Pour la fermeture en raison de la base d'avis: Je suis à la recherche d'un moyen technique de modifier de une lib statique cuit au four dans un endroit pdb

Answer 1

Jetez un oeil à l'option de liaison/PDBALTPATH. Cela vous permet de spécifier un chemin d'accès PDB différent qui sera intégré dans votre binaire.

/PDBALTPATH:pdb_file_name 

MSDN Article: /PDBALTPATH (Use Alternate PDB Path)