PROBLEM: (82808) (PATCH ID: OSF445-161) ******** This patch modifies the linker's symbol resolution to enable it to recognize when a reference to a symbol defined in a shared library is replaced by a symbol defined in an object file or archive. Previously, the linker failed to handle this replacement consistently when a symbol was defined by both a shared library and an object or archive that followed it on the linker command line. This would frequently lead to failed links reporting "multiply defined symbol" errors. This patch also modifies the linker to cause it to rescan shared libraries before reporting unresolved symbols. Symbols are sometimes added to the linker's list of unresolved symbols because the references to those symbols appear in object files or archives that are linked in after the shared libraries in which the symbols are defined. This final scan allows all symbol definitions to be recognized, and no symbols are misreported as being unresolved. In the following example, if the symbol "a" is defined in b.so and c.o and referenced in a.o, then without this patch, the linker behavior would be: cc a.o b.so c.o -rpath . ld: c.o: a: multiply defined With this patch, the linker will successfully perform the link using the definition of the symbol "a" from c.o. Using the following example for the second problem described, if the symbol "a" were defined in b.so and referenced from c.o, the linker would report an unresolved symbol error. ld -call_shared /usr/lib/cmplrs/cc/crt0.o a.o b.so -lc c.o ld: Unresolved: a With this patch, the linker will successfully perform the link. PROBLEM: (77290, 78669, 82501) (PATCH ID: OSF445-156) ******** PROBLEM: Using the -f switch with the linker (ld) produces link errors such as: ld: /usr/.../libc.a(file.o): write_outbuf: Not enuf room in bfr f_outbuf? nbytes(1264) > left(0) PROBLEM: Any switch that begins with -f and is not a legal switch to the linker gets interpreted to mean -f. For example '-funfun' is taken to mean -f. PROBLEM: (78237) (PATCH ID: OSF445-169) ******** his problem occurs if a program references the linker defined symbol _fpdata and the linker does not use this symbol. A case where this might be seen is the case of a program in which no exception handling is being used. An executable with this problem would not get any errors linking, but if you did the following command on the executable: nm -xv myprog.exe | grep fpdata you would get the following output: _fpdata | 0x00000000000000 | U | 0x00000000000000 Also, doing this: odump -jf myprog.exe | grep -i null you would see a line such as the following (with a different address): 0x120006f28 REFQUAD After the patch, you will not see the null using the odump command, and using the nm command you will get something like this: _fpdata | 0x00000000000000 | A | 0x00000000000008 If the linker makes use of the _fpdata symbol, then this problem does not arise. PROBLEM: (87682) (PATCH ID: OSF445-243) ******** The linker may incorrectly optimize the "jsr" Alpha instruction when linking large applications at -O2 or higher. This could result in an incorrect function call. The likelihood of encountering this problem is extremely rare because numerous low-level conditions must also be true during the link. PROBLEM: (69399, 72512, 78042) (PATCH ID: OSF445-228) ******** When something was compiled -shared or -call_shared, the .text symbol was not being set to the address where .text started. To see this, compile a simple hello world program with -call_shared set. Use odump to see where .text starts: odump -hv a.out | more and get output including something like this: .text 0x0000000120000fd0 0x0000000120000fd0 0x00000000000003c0 ^^^ addr A 0x0000000000000fd0 0x0000000000000000 0x0000000000000000 0 0 REG, TEXT Then look at the value of the symbol in the executable: nm -xv a.out | grep "\.text" and get output like this: .text | 0x00000120001030 | T | 0x00000000000000 ^^^ addr B The symbol value marked as 'addr A' should be the same as that marked as 'addr B'. This problem becomes most apparent when trying to use the symbol '.text' in some way. The symbols _BASE_ADDRESS, __tlskey, _DYNAMIC, _GOT_OFFSET, _gp had the wrong type set in the dynamic symbol table. To see this, build a program which uses __tlskey, and use this command: odump -Dtv end.so note in the output [ 26] __tlskey 0x000003ffffff07e0 0 LOCAL SECTION ABS 0 Here __tlskey has a type of ABS, when it should be TEXT. A similar situation exists with the other 4 symbols. This problem became more apparent when a library using TLS data was loaded into a place other than its quickstart address. Because __tlskey was of type ABS, the loader did not update __tlskey and the TLS initialization failed. This patch should be installed whether or not the problem is being seen. PROBLEM: (93921) (PATCH ID: OSF445-455) ******** This patch fixes a problem in the linker, which may cause segmentation violations in an executable that uses the address of an uninitialized data symbol defined in a shared library as the initial value of a global or static pointer variable. Imported addresses used as initial values in this manner are normally adjusted at runtime by the dynamic loader when a shared library cannot be mapped at its quickstart address. This is the text base address that the linker assumes will be the runtime address for the library. Without this patch, the linker will omit certain dynamic relocations, which are needed by the loader to make the proper address adjustments at runtime. Programs that are susceptible to this bug will run without error as long as all of the dependent shared libraries are loaded at their quickstart addresses. However, a segmentation violation may occur when a shared library cannot be loaded at its quickstart address. It is also possible for this problem to manifest with indeterminate symptoms. The invalid quickstart addresses that could not be adjusted by the loader may, in fact, reference valid address ranges in a different shared library. The symptoms will depend on how the pointer variables are used by the program.