Des avertissements LNK4099 peuvent se produire lors de la création sous Windows pendant la phase de liaison d'une compilation statique.
Par exemple. lors de la construction à l'aide de nmake et VC10, j'obtiens un flux d'avertissements LNK4099 comme:
libcurl_a_debug.lib(rc2_cbc.obj) : warning LNK4099: PDB 'lib.pdb' was not found with 'libcurl_a_debug.lib(rc2_cbc.obj)' or at 'C:\dev\scaler\center\dlux\lib.pdb'; linking object as if no debug info
StackOverflow donne un bon aperçu du problème , mais pas les détails nécessaires pour le comprendre.
Plutôt que ignorer l'avertissement ou désactiver l'avertissement , je voudrais corriger les makefiles dans ma build pour supprimer le problème.
Comment le problème se pose-t-il? Comment supprimer la cause des avertissements?
Comprenez que le problème sous-jacent est un fichier de symboles de débogage manquant (.pdb) pour la bibliothèque mentionnée dans l'avertissement. Les fichiers de bibliothèque contiennent une référence statique au .pdb sur la base d'un fichier objet. Lorsqu'une bibliothèque est utilisée par une autre bibliothèque et qu'une compilation statique est utilisée, Visual Studio collecte tous les symboles dans un seul .pdb et les références .pdb dans les fichiers objets sont mises à jour. Cependant, s'il ne trouve pas les symboles, il laissera l'ancien chemin en place.
Corrigez l'avertissement en recompilant la bibliothèque mentionnée dans les avertissements et assurez-vous que le compilateur a accès au .pdb de chaque bibliothèque référencée. Cela implique de déterminer quel fichier .pdb est introuvable, puis d'apporter des modifications pour garantir que le fichier .pdb puisse être trouvé.
Pour quel fichier objet (et donc bibliothèque) manque-t-il les symboles (.pdb) pour?
@ gothfourni un lien de blog expliquant d'où vient la référence .pdb , mais voici mon résumé:
Une bibliothèque contient un certain nombre de fichiers objets. Chaque fichier objet comprend un chemin d'accès aux symboles de débogage. Nous pouvons utiliser des outils pour extraire ces informations. Sur la base du fichier objet et du chemin, nous pouvons déterminer quel fichier de symboles de débogage (.pdb) est introuvable.
Ouvrez l'invite de commandes Visual Studio. Cela crée un shell de commande avec les variables d'environnement requises pour accéder aux outils Visual Studio. (Doit être sous "Visual Studio Tools" enterré dans le menu Démarrer, mais cela varie)
Obtenez le chemin interne du fichier objet dans la bibliothèque à l'aide de l'outil lib
/list
option. Par exemple.
C:\dev\libcurl\win\lib>lib /list libcurl_a_debug.lib > list_of_object_files_in_library.txt
C:\dev\scaler\center\agent\thirdparty\libcurl\win\lib>more list_of_object_files_in_library.txt
Microsoft (R) Library Manager Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
..\builds\libcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/file.obj
..\builds\libcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/timeval.obj
..\builds\libcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/rc2_cbc.obj
...
lib
/extract
option.C:\dev\scaler\center\agent\thirdparty\libcurl\win\lib>lib /extract:..\builds\libcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/timeval.obj libcurl_a_debug.lib
Microsoft (R) Library Manager Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
.debug$T
que nous pouvons extraire à l'aide de l'outil dumpbin
. Par exemple.C:\dev\scaler\center\agent\thirdparty\libcurl\win\lib>dumpbin /section:.debug$T /rawdata rc2_cbc.obj > dump_of_object_file_debug_info.txt
C:\dev\scaler\center\agent\thirdparty\libcurl\win\lib>more dump_of_object_file_debug_info.txt
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ./rc2_cbc.obj
File Type: COFF OBJECT
SECTION HEADER #9
.debug$T name
0 physical address
0 virtual address
5C size of raw data
1D53 file pointer to raw data (00001D53 to 00001DAE)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42100040 flags
Initialized Data
Discardable
1 byte align
Read Only
RAW DATA #9
00000000: 04 00 00 00 56 00 15 15 03 7A 47 A3 3D 4A 8C 4B ....V....zGú=J.K
00000010: A2 A5 26 D3 D6 57 15 46 3A 00 00 00 73 3A 5C 73 óÑ&ËÍW.F:...s:\s
00000020: 63 61 6C 65 78 2E 6E 65 77 5C 63 65 6E 74 72 6F caler.new\center
00000030: 5C 6F 70 65 6E 73 73 6C 5C 62 75 69 6C 64 5C 6F \openssl\build\o
00000040: 70 65 6E 73 73 6C 2D 31 2E 30 2E 30 62 5C 74 6D penssl-1.0.0b\tm
00000050: 70 33 32 5C 6C 69 62 2E 70 64 62 00 p32\lib.pdb.
Summary
5C .debug$T
Ci-dessus, vous voyez que le fichier objet indique ses symboles de débogage s:\scaler.new\center\openssl\build\openssl-1.0.0b\tmp32\lib.pdb
. Par conséquent, le problème réside dans le fichier .pdb généré lorsque nous avons créé la bibliothèque openssl utilisée par libcurl.
Comment ajouter les symboles de débogage à la bibliothèque générant l'avertissement?
L'option / Fd régit le nom et l'emplacement du fichier de symboles .pdb . Par exemple. lors de la compilation de libcurl, j'ai utilisé les drapeaux suivants:
...
!IF DEFINED(VC10)
NT_MAK_FLAGS = APP_CFLAG="/GX /GZ /MTd /Fdtmp32.dbg/app" LIB_CFLAG="/Zl /Z7 /Fdtmp32.dbg/lib"
!ENDIF
...
Le nom du fichier de symboles de lib.pdb
et son chemin par rapport à la construction est donné par /Fdtmp32.dbg/lib
.
Le problème est que le NT_MAK_FLAGS
est réutilisé pour un certain nombre de bibliothèques qui sont générées lorsque openssl est compilé. Par conséquent, lib.pdb
est écrasé (écrasé) pour toutes les bibliothèques sauf la dernière. Pour résoudre le problème, chaque bibliothèque doit recevoir .pdb avec un nom unique. Pour simplifier encore les choses, assurez-vous que l'emplacement de compilation se trouve dans la même arborescence que la génération libcurl
.
Cela m'est arrivé avec une bibliothèque .lib et peut-être que l'image ci-jointe aidera les autres. Dans mon cas, je devais m'assurer que le fichier .lib et le fichier .pdb se trouvaient dans le même répertoire, notez donc comment $ (OutDir) apparaît dans les paramètres.
Je pense qu'ils se sont désalignés lorsque j'ai importé un ancien projet VS2010 32 bits dans VS2013 et que je l'ai configuré pour 64 bits.
Je me retrouve donc avec cette (bonne) situation: