{"id":4323,"date":"2009-07-21T12:57:00","date_gmt":"2009-07-21T12:57:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2009\/07\/21\/linker-warning-lnk4221-and-some-tips-to-avoid-it\/"},"modified":"2019-02-18T18:45:49","modified_gmt":"2019-02-18T18:45:49","slug":"linker-warning-lnk4221-and-some-tips-to-avoid-it","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/linker-warning-lnk4221-and-some-tips-to-avoid-it\/","title":{"rendered":"Linker warning LNK4221, and some tips to avoid it"},"content":{"rendered":"

Hello, my name is Chandler Shen, a developer from Visual C++ Shanghai team.<\/font><\/p>\n

There is some confusion about warning <\/font>LNK4221<\/font><\/a> and whether it is safe to ignore it. I would like to give an explanation on when you may encounter this warning and provide tips for some typical scenarios and workarounds.<\/font><\/p>\n

What does LNK4221 mean?<\/font><\/font><\/font><\/span><\/h2>\n

 <\/font><\/p>\n

When building static\/import libraries, linker might emit the following message:<\/font><\/p>\n

\u201cwarning LNK4221: no public symbols found; archive member will be inaccessible\u201d (The message will be improved in VS2010 to \u201dwarning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library\u201d).<\/font><\/p>\n

Just as the message says, this warning occurs when an object file was added to an archive library without any previously undefined public symbols, so it will not be accessible in subsequent linker commands.<\/font><\/p>\n

Though this warning can be safely ignored sometimes, user should be aware of what\u2019s happening beneath the surface.<\/font><\/p>\n

Example<\/font><\/font><\/b><\/p>\n

Create two source files, a.cpp and b.cpp, with following contents<\/font><\/p>\n

\/\/ a.cpp<\/font><\/p>\n

#include <atlbase.h><\/font><\/p>\n

 <\/font><\/p>\n

\/\/ b.cpp<\/font><\/p>\n

#include <atlbase.h><\/font><\/p>\n

int func1()<\/font><\/p>\n

{<\/font><\/p>\n

    return 0;
}<\/font><\/p>\n

 <\/font><\/p>\n

In \u201d Visual Studio 2008 Command Prompt\u201d, enter the following commands (Note: We use command line here to specify the order of .obj files; Visual Studio 2008 will supply linker with .obj files in alphabetical order)<\/font><\/p>\n

1.<\/font><\/em>       <\/span><\/span><\/span>cl \/c a.cpp b.cpp<\/em><\/font><\/p>\n

2.<\/font><\/em>       <\/span><\/span><\/span>link \/lib \/out:test.lib a.obj b.obj<\/font><\/em><\/p>\n

And LNK4221 will be thrown for a.obj as the following.<\/font><\/p>\n

a.obj : warning LNK4221: no public symbols found; archive member will be inaccessible<\/font><\/em><\/p>\n

For the above case, atlbase.h (shipped with Visual Studio) contains some definitions of symbols, which will be included in both a.obj and b.obj. Additionally, there is a function, func1, defined in b.obj. Linker will process OBJ files in L<\/b>ast I<\/b>n F<\/b>irst O<\/b>ut manner, so when it is processing a.obj, it cannot find any new public symbols in it because b.obj provide all the public symbols that a.obj has, LNK4221 will be thrown. If command line 2 is replaced with following<\/font><\/p>\n

link \/lib \/out:test.lib b.obj a.obj<\/font><\/em><\/p>\n

Now the warning is gone!<\/font><\/p>\n

Typical user scenarios <\/font><\/font><\/font><\/span><\/h2>\n

In practice, most LNK4221 warnings occur on stdafx.obj, which is the name of the precompiled header. In this section, we will focus on two typical \u201creal-world\u201d scenarios and provide corresponding workarounds.<\/font><\/p>\n

Build a static library with object files<\/font><\/font><\/font><\/span><\/h2>\n

Generally, LNK4221 should not be thrown on stdafx.obj. But in some cases, such as migrating from other IDEs or project systems, there are more than one source files which are specified with \/Yc, hence the .obj files of them will all contain the content from stdafx.obj, if any of them is processed prior to stdafx.obj, a LNK4221 will be thrown. If this occurs, try following steps to check your configuration of Precompiled Headers.<\/font><\/p>\n

 <\/font><\/span><\/span>1.<\/font>       <\/span><\/span><\/span>In the Property Dialog of the project, select \u201cConfiguration Properties<\/b>\u201d->\u201dC\/C++<\/b>\u201d->\u201dPrecompiled Headers<\/b>\u201d. Select \u201cUse Precompiled Header (\/Yu)<\/b>\u201d for \u201cCreate\/Use Precompiled Header<\/b>\u201d, and accept the default values for the other two options.<\/font><\/p>\n

<\/p>\n

2.<\/font>       <\/span><\/span><\/span>Right click \u201cstdafx.cpp\u201d in solution explorer. Select \u201cProperties\u201d, then select \u201cConfiguration Properties<\/b>\u201d -> \u201dC\/C++<\/b>\u201d -> \u201cPrecompiled Headers<\/b>\u201d. Select \u201cCreate Precompiled Header (\/Yc)<\/b>\u201d for \u201cCreate\/Use Precompiled Header<\/b>\u201d, and accept the default values for other two options.<\/font><\/p>\n

<\/p>\n

3.<\/font>       <\/span><\/span><\/span>Save the changes and rebuild the project. If the problem remains, check the build log to confirm that only one source file (\u201cstdafx.cpp\u201d here) is compiled with \/Yc and the others are compiled with \/Yu.<\/font><\/p>\n

<\/p>\n

 <\/font><\/span><\/h2>\n

Build a static library with other static libraries<\/font><\/font><\/font><\/span><\/h2>\n

Sometimes, the user would like to build a single static library from existing libraries for convenience. This approach might \u201clead to\u201d multiple LNK4221 warnings, especially when the user changed the settings of output path of these libraries. To begin with, create a simple test case as follows<\/font><\/p>\n

1.<\/font>       <\/span><\/span><\/span>In Visual Studio 2008, create a \u201cBlank Solution<\/b>\u201d,  and name it \u201csolution1<\/b>\u201d.<\/font><\/p>\n

2.<\/font>       <\/span><\/span><\/span>Add three new \u201cWin32 Project<\/b>s\u201d, lib1, lib2 and wrapperlib, into solution1, and in the \u201cApplication Settings<\/b>\u201d page of the wizard, select \u201cStatic library<\/b>\u201d for \u201cApplication type<\/b>\u201d, check \u201cPrecompiled header<\/b>\u201d for \u201cAdditional options<\/b>\u201d, and check \u201cMFC<\/b>\u201d for \u201cAdd common header files for<\/b>\u201d.<\/font><\/p>\n

3.<\/font>       <\/span><\/span><\/span>Add a new source file, lib1.cpp, into project lib1 with following code<\/font><\/p>\n

#include <stdafx.h><\/font><\/p>\n

 <\/font><\/span><\/p>\n

int func1()<\/font><\/p>\n

{<\/font><\/p>\n

     return 1;<\/font><\/p>\n

}<\/font><\/p>\n

4.<\/font>       <\/span><\/span><\/span>Add a new source file, lib2.cpp, into project lib2 with following code<\/font><\/p>\n

#include <stdafx.h><\/font><\/p>\n

 <\/font><\/p>\n

int func2()<\/font><\/p>\n

{<\/font><\/p>\n

     return 1;<\/font><\/p>\n

}<\/font><\/p>\n

5.<\/font>       <\/span><\/span><\/span>In the Property Dialog of wrapperlib, select \u201cConfiguration Properties<\/b>\u201d -> \u201cLibrarian<\/b>\u201d -> \u201cGeneral<\/b>\u201d, enter \u201clib1.lib lib2.lib<\/b>\u201d in \u201cAdditional Dependencies<\/b>\u201d, and enter \u201c$(OutDir)<\/b>\u201d in \u201cAdditional Library Directories<\/b>\u201d.<\/font><\/p>\n

After all projects are created, build all libraries in the order of lib1, lib2 and wrapperlib.lib, everything should go well except an informative message as following will be shown:<\/font><\/p>\n

\u201cReplacing .\\Debug\\stdafx.obj\u201d<\/font><\/em><\/p>\n

The reason why you see the message is because the linker builds a library from some object files and static libraries. It will attempt to replace archive members of input libraries with those in the command line with the same name. In this case, because \u201c.\\Debug\\stdafx.obj\u201d was used as the name of the corresponding archive member of stdafx.obj for all three libraries. When linker is processing the \u201c.\\Debug\\stdafx.obj\u201d in command line (the command line used to build wrapperlib.lib would look like \u201clink \/lib \/out:wrapperlib.lib .\\Debug\\stdafx.obj lib1.lib lib2.lib\u201d), it finds that both lib1 and lib2 contain a member with same name, so linker will exclude these two from linking. Therefore, no other files will contain symbols defined in this \u201cstdafx.obj\u201d.<\/font><\/p>\n

To verify the above explanation, perform the following steps:<\/font><\/p>\n

1.<\/font>       <\/span><\/span><\/span>In the Property Dialog of lib1, select \u201cConfiguration Properties<\/b>\u201d -> \u201cGeneral<\/b>\u201d, set \u201cIntermediate Directory<\/b>\u201d with \u201c$(SolutionDir)\/intermediate\/$(ConfigurationName)\/$(ProjectName)<\/b>\u201d, which is a common style of project hierarchy for some users.<\/font><\/p>\n

2.<\/font>       <\/span><\/span><\/span>Rebuild lib1 and wrapperlib, and following warning will be shown.<\/font><\/p>\n

stdafx.obj : warning LNK4221: no public symbols found; archive member will be inaccessible.<\/font><\/em><\/p>\n

 <\/font><\/p>\n

Is it (both the replacement mechanism and the LNK4221) a bug of linker? The answer is no, because:<\/font><\/p>\n

1.<\/font>       <\/span><\/span><\/span>Linker should be very cautious about not dropping any useful object in a library just because its name conflicts with that of another object<\/font><\/p>\n

2.<\/font>       <\/span><\/span><\/span>If something unusual happens (an object contributes no new symbols to archive), user should be informed.<\/font><\/p>\n

Workarounds<\/font><\/font><\/font><\/span><\/h2>\n

Since this warning is widely reported , the following workaround is recommended<\/font><\/p>\n

Perform following steps to replace \u201cstdafx.obj\u201d in input libraries manually.<\/font><\/p>\n

1.<\/font>       <\/span><\/span><\/span>In \u201cVisual Studio 2008 Command Prompt\u201d, enter the following command for each input libraries.<\/font><\/p>\n

lib \/remove:.\\Debug\\stdafx.obj lib1.lib<\/font><\/em><\/p>\n

The name after \u201c\/remove\u201d depends on your actual settings,  you can use the following commad to confirm<\/font><\/p>\n

dumpbin \/archivemembers lib1.lib<\/font><\/em><\/p>\n

2.<\/font>       <\/span><\/span><\/span>If some of \u201cstdafx.obj\u201d are not identical <\/b>in content, you should merge all \u201cstdafx.obj\u201d into the one in wrapperlib.lib beforehand.<\/font><\/p>\n

a.<\/font>       <\/span><\/span><\/span>Delete all contents in the stdafx.h from wrapperlib.lib<\/font><\/p>\n

b.<\/font>      <\/span><\/span><\/span>Inspect all stdafx.h from input libraries (lib1.lib, lib2.lib, etc.), if there is any content (such as an \u201c#include\u201d clause) that is not included in the one from wrapperlib.lib, add it. If there are conflicting definitions, it\u2019s up to you which one is to be used.<\/font><\/p>\n

c.<\/font>       <\/span><\/span><\/span>Repeat step b until all stdafx.h from input libraries are inspected, so the one from wrapperlib.lib will contain all contents.<\/font><\/p>\n

3.<\/font>       <\/span><\/span><\/span>Build wrapperlib.lib<\/font><\/p>\n

<\/p>\n

If you don\u2019t want to work around this linker warning, just ignore LNK4221. However, you should be sure that all \u201cstdafx.obj\u201d are identical in content.<\/span><\/p>\n

<\/font><\/p>\n

 <\/font><\/p>\n","protected":false},"excerpt":{"rendered":"

Hello, my name is Chandler Shen, a developer from Visual C++ Shanghai team. There is some confusion about warning LNK4221 and whether it is safe to ignore it. I would like to give an explanation on when you may encounter this warning and provide tips for some typical scenarios and workarounds. What does LNK4221 mean? […]<\/p>\n","protected":false},"author":289,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-4323","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","tag-linker"],"acf":[],"blog_post_summary":"

Hello, my name is Chandler Shen, a developer from Visual C++ Shanghai team. There is some confusion about warning LNK4221 and whether it is safe to ignore it. I would like to give an explanation on when you may encounter this warning and provide tips for some typical scenarios and workarounds. What does LNK4221 mean? […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4323","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/289"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=4323"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4323\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=4323"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=4323"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=4323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}