Yu-Jing Chen wrote: > Core was generated by `/usr/ccs/bin/ld -Qy -o executable.pure.x /usr/lo'. > Program terminated with signal 11, Segmentation fault. > (gdb) where > #0 0xfea36a10 in sym_enter () from /usr/ccs/bin/../../../lib/libld.so.2 > #1 0xfea38b04 in sym_process () from /usr/ccs/bin/../../../lib/libld.so.2 > #2 0xfea2a2d4 in process_elf () from /usr/ccs/bin/../../../lib/libld.so.2 > #3 0xfea2a7d8 in process_ifl () from /usr/ccs/bin/../../../lib/libld.so.2 > #4 0xfea2a9a8 in process_open () from /usr/ccs/bin/../../../lib/libld.so.2 > #5 0xfea437a4 in process_files_com () from > /usr/ccs/bin/../../../lib/libld.so.2 > #6 0xfea438a4 in process_files () from /usr/ccs/bin/../../../lib/libld.so.2 > #7 0xfea45448 in ld_main () from /usr/ccs/bin/../../../lib/libld.so.2 > #8 0x00011220 in main ()
This trace tells me we're processing an input file, and are reading the symbols from that file. So, let's find out what file this is and try and narrow things down. Set LD_OPTIONS=-Dfiles and run the link-edit. You should easily be able to determine which file ld(1) is working on. I'd suspect, that once you've determined the file, a simple link-edit of just this file, will show the same failure (ie. ld <bad-file>). Inspect the file with elfdump(1) (ie. elfdump <bad-file>). elfdump does more ELF file sanity checking than ld(1) and might reveal something is wrong with the file. elfdump() might also core dump itself :-) If you have isolated a bad file, and are still at a loss, forward the one file to me. If the customer is troubled with handing over "proprietary information", have them run mcs -z on the file. This will nuke all code in the file, and just leave the ELF information, which should be all we need to analyze the linking problem -- Rod.
