\nLast time, we learned the basics of\n\nthe classical model for linking<\/A>.\nToday, we’ll look at the historical background for that model,\nand how the model is exploited by libraries.\n<\/P>\n \nIn the classical model,\ncompilers and assemblers consume source code and spit out\nan OBJ file.\nThey do as much as they can, but eventually they get stuck\nbecause they don’t have the entire module at their disposal.\nTo record the work remaining to be done, the OBJ file contains\nvarious sections:\na data section, a code section (historically\nand confusingly called text<\/I>),\nan uninitialized data section, and so on.\nThe linker resolves symbols, and then for each OBJ file\nthat got pulled into the module,\nit combines all the code sections into one giant code section,\nall the data sections into one giant data section, and so on.\n<\/P>\n \nOne thing you may have noticed is that the unit of consumption\nis the OBJ file.\nIf an OBJ file is added to the module,\nthe whole thing gets added,\n\neven if you needed only a tiny part<\/A>\nof the OBJ file.\nHistorically,\nthe reason for this rule is that the compilers and assemblers\ndid not include information in the OBJ file to indicate\nhow to separate all the little pieces.\nIt’s like if somebody said,\n“Can you get me a portable mp3 player?”\nand the only thing available in the library\nwas a smartphone.\nSure, it plays mp3 files, but there’s a lot of other\nelectronic junk in there that you didn’t<\/I> ask for,\nbut it came along for the ride.\nAnd you don’t know how to disassemble the smartphone\nand extract just the mp3-player part.\n<\/P>\n \nThis behavior is actually exploited as a feature<\/I>,\nbecause it allows for tricks like this:\n<\/P>\n \/* magicnumber.c *\/\nint magicNumber;<\/p>\n class InitMagicNumber\n{\n InitMagicNumber()\n {\n magicNumber = …;\n }\n}\ng_InitMagicNumber;\n<\/PRE>\n\n\/* magicnumber.h *\/\nextern int magicNumber;<\/p>\n