{"id":5613,"date":"2013-01-09T07:00:00","date_gmt":"2013-01-09T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2013\/01\/09\/understanding-the-classical-model-for-linking-you-can-override-an-lib-with-another-lib-and-a-lib-with-an-obj-but-you-cant-override-an-obj\/"},"modified":"2020-07-31T07:17:03","modified_gmt":"2020-07-31T14:17:03","slug":"understanding-the-classical-model-for-linking-you-can-override-an-lib-with-another-lib-and-a-lib-with-an-obj-but-you-cant-override-an-obj","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20130109-00\/?p=5613","title":{"rendered":"Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can’t override an OBJ"},"content":{"rendered":"

If you study the classical model for linking<\/a>, you’ll see that OBJ files provided directly to the linker have a special property: They are added to the module even if nobody requests a symbol from them<\/i>.<\/p>\n

OBJs bundled into a library are pulled into the module only if they are needed to resolve a needed<\/i> symbol request. If nobody needs a symbol in the OBJ, then the OBJ doesn’t get added to the module. On the other hand, OBJs handed directly to the linker get added to the module whether anybody wants them or not<\/i>.<\/p>\n

Last time, we learned about the along for the ride<\/i> technique<\/a> which lets you pull components into a module even if they were not explicitly requested by an OBJ. Today’s problem is sort of the reverse of this: If you move an OBJ from the explicit OBJ list to a library, then somebody has to remember to take it for a ride.<\/p>\n

Some time ago, Larry Osterman described how some components use sections to have one component automatically register itself with another component when the OBJ is pulled into the module<\/a>. But in order for that to work, you have to make sure the OBJ gets pulled into the module in the first place. (That’s what Larry’s Call\u00adForce\u00adLoad<\/code> function is for: By putting it an explicit OBJ, that function forces the OBJ from the LIB to be pulled in. And then, since nobody ever calls Call\u00adForce\u00adLoad<\/code>, a later linker pass discards it as an unused function.)<\/p>\n

Another consequence of the algorithm by which the linker pulls OBJs from libraries to form a module is that if a needed<\/i> symbol can be satsified without consulting a library, then the OBJ in the library will not be used. This lets you override a symbol in a library by explicitly placing it an OBJ. You can also override a symbol in a library to putting it in another<\/i> library that gets searched ahead of the one you want to override. But you can’t override a symbol in an explicit OBJ, because those are part of the initial conditions.<\/p>\n

Exercise<\/b>:<\/p>\n

Discuss this user’s analysis of a linker issue.<\/p>\n

\n

I have three files:<\/p>\n

\/\/ awesome1.cpp\r\nint index;\r\n\r\n\/\/ awesome2.cpp\r\nextern int index;\r\nvoid setawesomeindex(int i)\r\n{\r\n index = i;\r\n}\r\n\r\n\/\/ main.cpp\r\nint index = 0;\r\nint main(int, char**)\r\n{\r\n setawesomeindex(3);\r\n return index;\r\n}\r\n<\/pre>\n
When I link the object files together, I get an error complaining that index<\/code> is multiply defined, as expected. On the other hand, if I put awesome1.cpp<\/code> and awesome2.cpp<\/code> into a library, then the program links fine, but the two copies of the index<\/code> variable were merged by the linker! When I set the awesome index to 3, it also changes my main program’s variable index<\/code> which has the same name. Why is the linker merging my variables, and how can I keep them separate?<\/p>\n
When I share my awesome.lib<\/code> with others, I don’t want to have to give them a list of all my global variables and say, “Don’t create a global variable with any of these names, because they will conflict with my library.” (And that would also prevent me from adding any new global variables to my library.)<\/p>\n<\/blockquote>\n
Exercise<\/b>: Clarify the following remark by making it more precise and calling out the cases where it is false. “Multiple definitions for a symbol are allowed if they appear in LIBs.”<\/p>\n
Exercise (harder)<\/b>: The printf<\/code> function is in a bit of a pickle regarding whether it should support the floating point formats. If it includes them unconditionally, then its use of the floating point data types causes the floating point emulation library to be linked into the module, even if the module didn’t otherwise use floating point! Use what you’ve learned so far this week to provide one way that the printf<\/code> function could determine whether it should include floating point format support based on whether the module uses floating point.<\/p>\n","protected":false},"excerpt":{"rendered":"
If you study the classical model for linking, you’ll see that OBJ files provided directly to the linker have a special property: They are added to the module even if nobody requests a symbol from them. OBJs bundled into a library are pulled into the module only if they are needed to resolve a needed […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25,131],"class_list":["post-5613","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code","tag-linker"],"acf":[],"blog_post_summary":"
If you study the classical model for linking, you’ll see that OBJ files provided directly to the linker have a special property: They are added to the module even if nobody requests a symbol from them. OBJs bundled into a library are pulled into the module only if they are needed to resolve a needed […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/5613","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=5613"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/5613\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=5613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=5613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=5613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}