Why Error L2044 Suggests Using /NOE[XTDICTIONARY] Option

MS-DOS                                | OS/2

The information in this article applies to:

• Microsoft LINK for MS-DOS, versions 3.x, 4.x, 5.0x, 5.1x, 5.2, 5.3x, 5.5, and 5.6
• Microsoft LINK for OS/2, versions 5.0x, 5.1, 5.11, 5.13, and 5.15

SUMMARY

When the Microsoft LINK command line does not include the /NOE option and the object modules contain more than one definition of a symbol, LINK generates the following message:

   L2044 : 'symbol' : symbol multiply defined, use /NOE

   LINK found what it interprets as a public-symbol redefinition,
   probably because a symbol defined in a library was redefined.

   Relink with the /NOE option. If error L2025 results for the same
   symbol, then this is a genuine symbol-redefinition error.

MORE INFORMATION

The Microsoft Library utility (LIB) creates an extended dictionary when it builds a library, unless the LIB command line includes the /NOE option switch. The extended dictionary contains cross-references between the modules. For example, if Mod1 and Mod2 are modules in a library and function A() in Mod1 calls function B() in Mod2. In this relationship, Mod1 is termed the "primary" module and Mod2 is termed the "secondary" module.

   Mod1: Primary Module    Mod2: Secondary Module

     ______________          ______________
    |              |        |              |
    |   A( )       |        |   B( )       |
    |   {          |        |   {          |
    |      B( )    |        |              |
    |   }          |        |   }          |
    |______________|        |______________|

LINK can use this information to speed the linking process. First, LINK finds all symbols in the specified object modules and uses them to resolve any external references. If any symbols remain unresolved, LINK searches the specified libraries for these symbols and loads the modules that resolve the symbols.

For example, consider the process of linking a program that calls function A() but does not include the code for A() with a library that contains Mod1 and Mod2 above. After searching in the object module, A() remains unresolved. When it searches the library, LINK finds A() defined in Mod1 and loads that module. If it uses the extended dictionary, LINK also loads Mod2, to automatically resolve the call to B(). If LINK does not use the extended dictionary, LINK finds that B() is an unresolved symbol and it must search the libraries once again.

In general, if an application requires many libraries, the process of resolving the symbols in primary modules proceeds much faster when the secondary modules are loaded with their corresponding primary modules.

The following example demonstrates how using the extended dictionary can cause a symbol redefinition.

                 Primary Modules       Secondary Modules
                 ______________         ______________
                |              |       |              |
                |   X( )       |       |   Z( )       |
    Library1:   |   {          |       |   {          |
                |      Z( )    |       |              |
                |   }          |       |   }          |
                |______________|       |______________|

                 ______________         ______________
                |              |       |              |
                |   Y( )       |       |   Z( )       |
    Library2:   |   {          |       |   {          |
                |      Z( )    |       |              |
                |   }          |       |   }          |
                |______________|       |______________|

Also, consider the process of linking an application that both calls and defines Z() with Library1. If LINK uses the extended dictionary, it loads the secondary module, which causes a redefinition of Z(). If LINK does not use the extended dictionary, the Z() call in function X() is resolved with the version of Z() defined in the application. Therefore, specifying the /NOE option eliminates this error.