Подтвердить что ты не робот

Как удалить предупреждение LNK4099: PDB 'lib.pdb' не найден

Предупреждения LNK4099 могут возникать при построении на Windows во время фазы ссылки статической компиляции.

например. при создании с использованием nmake и VC10 я получаю поток предупреждений LNK4099, например:

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 дает хороший обзор проблемы, но не детали, необходимые для его понимания.

Вместо игнорировать предупреждение или отключить предупреждение, я хотел бы исправить make файлы в моем чтобы удалить проблему.

Как возникает проблема? Как удалить причину предупреждений?

4b9b3361

Ответ 1

Поймите, что основной проблемой является отсутствующий файл символов отладки (.pdb) для библиотеки, упомянутой в предупреждении. Файлы библиотеки содержат статическую ссылку на .pdb на основе объектного файла. Когда библиотека используется другой библиотекой и используется статическая компиляция, Visual Studio собирает все символы в один .pdb, а ссылки .pdb в объектных файлах обновляются. Однако, если он не может найти символы, он оставит старый путь на своем месте.

Исправить предупреждение, перекомпилировав библиотеку, указанную в предупреждениях, и убедитесь, что у компилятора есть доступ к .pdb каждой библиотеки, на которую делается ссылка. Это включает в себя определение того, какой файл .pdb не может быть найден, а затем внесение изменений для обеспечения возможности поиска .pdb.

В каком объектном файле (и, следовательно, в библиотеке) отсутствуют символы (.pdb) для?

@goth предоставил ссылку в блоге, объясняющую, откуда ссылается ссылка .pdb, но вот мое резюме:

Библиотека содержит несколько объектных файлов. Каждый объектный файл содержит путь к отладочным символам. Мы можем использовать инструменты для извлечения этой информации. На основе объектного файла и пути мы можем выяснить, какой файл отладочных символов (.pdb) не найден.

  • Откройте командную строку Visual Studio. Это создает командную оболочку с переменными среды, необходимыми для доступа к инструментам Visual Studio. (Должно быть в разделе "Инструменты Visual Studio", зарыты в меню "Пуск", но это меняется)

  • Получить внутренний путь к объекту в библиотеке с помощью параметра lib tool /list. Например.

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

...
  1. Используя путь, извлеките объектный файл с помощью параметра lib tool /extract.
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.
  1. Объектный файл содержит раздел отладки .debug$T, который мы можем извлечь, используя инструмент dumpbin. Например.
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

Выше видно, что в объектном файле содержатся его отладочные символы s:\scaler.new\center\openssl\build\openssl-1.0.0b\tmp32\lib.pdb. Поэтому проблема заключается в генерации .pdb, когда мы построили библиотеку openssl, используемую libcurl.

Как добавить символы отладки в библиотеку, генерирующую предупреждение?

Параметр /Fd определяет имя и расположение файла символов .pdb. Например. при компиляции libcurl я использовал следующие флаги:

...
!IF DEFINED(VC10)
NT_MAK_FLAGS = APP_CFLAG="/GX /GZ /MTd /Fdtmp32.dbg/app" LIB_CFLAG="/Zl /Z7 /Fdtmp32.dbg/lib"
!ENDIF
...

Имя файла символа lib.pdb и его путь относительно сборки дается /Fdtmp32.dbg/lib.

Проблема в том, что NT_MAK_FLAGS повторно используется для нескольких библиотек, которые генерируются при компиляции openssl. В результате lib.pdb сбивается (перезаписывается) для всех, кроме последней библиотеки. Чтобы решить проблему, каждой библиотеке следует предоставить .pdb с уникальным именем. Чтобы упростить ситуацию, убедитесь, что место компиляции находится в том же дереве, что и сборка libcurl.

Ответ 2

Это случилось со мной с библиотекой .lib, и, возможно, прикрепленное изображение поможет другим. В моем случае я должен был убедиться, что файлы .lib и .pdb находятся в одном каталоге, поэтому обратите внимание, как в настройках появляется параметр $(OutDir).

убедитесь, что каталоги одинаковы

Я думаю, что они были смещены, когда я импортировал старый 32-битный VS2010-проект в VS2013 и установил его для 64 бит.

Итак, я заканчиваю эту (хорошую) ситуацию:

. lib и .pdb в том же каталоге