PROBLEM: (QAR 49301) (Patch ID: OSF410-400174) ******** This patch fixes a problem where use of "ld -r ..." will change symbol preemption behavior. Without this patch, some global relocations can be converted to locals as an optimization. These locals cannot be preempted. An undocumented linker option has been added in the patched linker to prevent this conversion. This new switch is "ld -no_local_conversion ..." PROBLEM: (QAR 53151) (Patch ID: OSF410-400375) ******** At link-time the linker issues an ASSERT statement from within the module relocate.c. This will only be observed for very large applications that build a final image based on previously linked 'ld -r' object files. The error produces output messages in the following form: assertion failed: EX at ../../../../../../src/usr/ccs/bin/ld/relocate.c line 2471 PROBLEM: (QAR 55440) (Patch ID: OSF410-400375) ******** Hidden/Export Symbol wildcard problem: A regression was introduced into the linker when -hidden symbol processing was scaled up to use a hash table. The wildcard capability with the "exported_symbol" option was completely lost. This fix makes wildcards functional for hidden/export symbols. An example of wildcard usage that was no longer functional is: ld -o libf.so -shared -all -hidden -exported_symbol 'X500*' file.o -lc Any symbol beginning with X500 should be "GLOBAL" not "LOCAL". To check if a symbol is global use the following odump command on the library that is produced by the linker: odump -Dt libf.so Shows the symbol being GLOBAL or LOCAL PROBLEM: (QAR 54224) (Patch ID: OSF410-400375) ******** The linker was improperly rounding -T values to 64K increments even when linking OMAGIC files, which do not have the same rounding requirements. It turns out that the check being made in the ld.c was already being done in layout, so all we really need to do is to remove the bogus check in ld.c PROBLEM: (QAR 55693) (Patch ID: OSF410-400375) ******** The linker fails to link a c^^ program issuing an "ld_munmap error" message. PROBLEM: (QAR 57068) (Patch ID: OSF410-405212) ******** This patch fixes a problem where the linker might crash when printing out lengthy error diagnostics. PROBLEM: (QAR 60767) (Patch ID: OSF410-405266) ******** This patch is a fix for a linker bug that could cause valid conflict symbols to not be recorded in the linked executable's conflict section. The following conditions are necessary to reproduce the problem fixed by this patch. - The application is linked -call_shared. - The application is large enough to require more than one Global Offset Table (GOT) in the executable. Multiple GOTs occur when the number of referenced external symbols in the application exceeds 8190. - The user adds a symbol to their application which has the same name as a symbol in one of the shared libraries used by the application. For example, if a user linked their own malloc routine into an application, the libc malloc routine may be used instead. If you think you're experiencing this problem, one way to quickly verify it is to set the _RLD_ARGS environment variable to "-force checksum". Setting this will force the loader to resolve all symbols and ensure that the proper symbols are used. Another option to determine if you're experiencing this problem is to dump the conflict symbol table from the linked executable. This is performed with "odump -Dc application_name". If you've added a symbol to your application and the symbol also exists in one of the shared libraries used by the application, then the symbol should be listed in the conflict symbol table. If it isn't, this patch may be required.