{"id":109818,"date":"2024-05-29T07:00:00","date_gmt":"2024-05-29T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109818"},"modified":"2024-06-02T07:44:10","modified_gmt":"2024-06-02T14:44:10","slug":"20240529-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240529-00\/?p=109818","title":{"rendered":"A graphical depiction of the steps in building a C++ executable, basics"},"content":{"rendered":"

One of the things you have to know when trying to diagnose a build failure is understanding what each step of the build accomplishes, so that you can fix the problem at the correct step.<\/p>\n

Here’s the basic idea.<\/p>\n

\u00a0<\/div>\n
\u00a0<\/div>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/td>\n <\/td>\n.h, .cpp<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nC++ compiler<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n.obj<\/td>\n<\/tr>\n
 <\/td>\n\u2199<\/td>\n\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193<\/td>\n<\/tr>\n
librarian<\/td>\n <\/td>\n<\/tr>\n
\u2193<\/td>\n <\/td>\n<\/tr>\n
.lib<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n\u2198<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nlinker<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n.dll, .exe<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Given a bunch of header files (.h) and C++ source files (.cpp), the C++ compiler produces a corresponding set of object files (.obj).\u00b9 If your project builds a library, then the object files are given to the librarian to produce a library file, and that’s your project. In other words, your library project uses only the top part of the diagram, through to building the .lib file, but doesn’t go down the other branch that leads to the linker.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/td>\n <\/td>\n.h, .cpp<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nC++ compiler<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n.obj<\/td>\n<\/tr>\n
 <\/td>\n\u2199<\/td>\n <\/td>\n<\/tr>\n
librarian<\/td>\n <\/td>\n<\/tr>\n
\u2193<\/td>\n <\/td>\n <\/td>\n<\/tr>\n
.lib<\/td>\n <\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

If your project builds an executable module (a .dll or .exe, for example), then the object files and any input libraries are given to the linker, which then generates the desired module file. In that case, you’re using the other branch of the diagram that leads to the linker:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/td>\n <\/td>\n.h, .cpp<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nC++ compiler<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n.obj<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n<\/tr>\n
.lib<\/td>\n <\/td>\n<\/tr>\n
 <\/td>\n\u2198<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nlinker<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n.dll, .exe<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Already you know enough to solve this problem:<\/p>\n

My solution consists of three projects<\/a>: A core library, a program that consumes the library, and a unit test that consumes that same library. I added some code to the core library, and now the program and unit test are generating linker errors due to a missing import library used by the code I added. I added that library to the core library’s Additional\u00adDependencies<\/tt>, but that didn’t fix it.<\/p><\/blockquote>\n

Next time, we’ll expand this diagram to include additional tools you may encounter in Windows projects.<\/p>\n

Answer to exercise<\/b>: The error complaining about the unresolved external symbol is coming from the linker, so you need to provide the library with that symbol to the linker. The core library project doesn’t run the linker: It runs the librarian to produce corelibrary.lib<\/tt>. It’s the program and unit test that consume the corelibrary.lib<\/tt> and produce contoso.exe<\/tt> and contoso_unittest.exe<\/tt>, respectively. Those are the projects that need the new library listed in the Additional\u00adDependencies<\/tt>.<\/p>\n

To avoid having to update both the program and unit test each time the build requirements of the core library change, you might put those special configuration settings in a separate file that is included by the program and unit test projects, so that any changes need to be made in only one place.<\/p>\n

\u00b9 For unix, the same principles apply, but the file extensions are different. The extension for object files is .o, the extensions for library files are .a and .so, depending on what type of library they are. And unix executables traditionally have no extension.<\/p>\n

\n