Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
471 views
in Technique[技术] by (71.8m points)

windows - How to remove warning LNK4099: PDB 'lib.pdb' was not found

LNK4099 warnings can occur when building on Windows during the link phase of a static compilation.

E.g. when building using nmake and VC10 I get a stream of LNK4099 warnings like:

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:devscalercenterdluxlib.pdb'; linking object as if no debug info

StackOverflow gives a good overview of the problem, but not the detail required to understand it.

Rather than ignore the warning or disable the warning, I would like to fix the makefiles in my build to remove the problem.

How does the problem arise? How do I remove the cause of the warnings?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

Understand that the underlying problem is a missing debug symbols file (.pdb) for the library mentioned in the warning. Library files contain a static reference to the .pdb on an object file basis. When a library is used by another library and static compilation is used, Visual Studio collects all the symbols into a single .pdb and the .pdb references in the object files are updated. However, if it cannot find the symbols, it will leave the old path in place.

Fix the warning by recompiling the library mentioned in the warnings, and make sure the compiler has access to the .pdb of every referenced library. This involves determining which .pdb file cannot be found, and then making changes to ensure the .pdb can be found.

Which object file (and thus library) are we missing the symbols (.pdb) for?

@goth provided a blog link explaining where the .pdb reference comes from, but here is my summary:

A library contains a number of object files. Each object file includes a path to the debug symbols. We can use tools extract this information. Based on the object file and path, we can figure out which debug symbols file (.pdb) could not be found.

  1. Open the Visual Studio Command Prompt. This creates a command shell with environment variables required to access Visual Studio tools. (Should be under "Visual Studio Tools" buried in the Start Menu, but this varies)

  2. Obtain the internal path of the object file in the library using the lib tool's /list option. E.g.

C:devlibcurlwinlib>lib /list libcurl_a_debug.lib > list_of_object_files_in_library.txt

C:devscalercenteragenthirdpartylibcurlwinlib>more list_of_object_files_in_library.txt
Microsoft (R) Library Manager Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

..uildslibcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/file.obj
..uildslibcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/timeval.obj
..uildslibcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/rc2_cbc.obj

...
  1. Using the path, extract the object file using the lib tool's /extract option.
C:devscalercenteragenthirdpartylibcurlwinlib>lib /extract:..uildslibcurl-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. The object file contains a debug section called .debug$T that we can extract using the dumpbin tool. E.g.
C:devscalercenteragenthirdpartylibcurlwinlib>dumpbin /section:.debug$T /rawdata rc2_cbc.obj > dump_of_object_file_debug_info.txt

C:devscalercenteragenthirdpartylibcurlwinlib>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.newcenter
  00000030: 5C 6F 70 65 6E 73 73 6C 5C 62 75 69 6C 64 5C 6F  openssluildo
  00000040: 70 65 6E 73 73 6C 2D 31 2E 30 2E 30 62 5C 74 6D  penssl-1.0.0bm
  00000050: 70 33 32 5C 6C 69 62 2E 70 64 62 00              p32lib.pdb.

  Summary

          5C .debug$T

Above, you see that the object file says its debug symbols s:scaler.newcenteropenssluildopenssl-1.0.0bmp32lib.pdb. Therefore, the problem lies with the .pdb generated when we built the openssl library used by libcurl.

How do I add the debug symbols to the library generating the warning?

The /Fd option governs the name and location of the .pdb symbols file. E.g. when compiling libcurl, I used the following flags:

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

The symbol file name of lib.pdb and its path relative to the build is given by /Fdtmp32.dbg/lib.

The problem is that the NT_MAK_FLAGS is reused for a number of libraries that are generated when openssl is compiled. As a result, lib.pdb is clobbered (overwritten) for all but the last library. To resolve the problem, each library should be given .pdb with a unique name. To simplify matters further, ensure that the compilation location is in the same tree as the libcurl build.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...