Dave Lin wrote: > Rod Evans wrote: >> Brian Lu wrote: >>> Hi, experts, >>> >>> Our RE got the following build error when I built pango(1.24.1) on >>> snv_116 sparc(/usr/ccs/bin/ld version is 5.11-1.1673), I didn't see >>> this problem on snv_114(ld version is 5.11-1.1666) and snv_116 x86. >>> .... >>> *pkgbuild: ld: elf error: file viewer-pangox.o: elf_strptr: Request >>> error: no string table* >> >> Is this reproducable? >> > Yes. I tried 3 times and no exception. > >> This is typically a sign that someone else is building/updating >> the relocatable object (viewer-pangox.o) at the same time ld(1) >> is trying to read it. ie. a parallel build issue? > I think you're right, when I disabled "-j", it passed. > "make -j $CPU" --> "make"
Interesting. Parallel build problems have a tendency to come and go. It would be informative to unravel who all is executed for the target that's failing. There are sometimes post processing steps on .o's that are filtered from the standard output (makefile lines start '@'); > It's wired that why it worked well with the lower ld version? ld(1) is complaining that an input file is corrupt, and should always have generated this error on a corrupt file, so perhaps we should be looking at who is manipulating the relocatable object, and how that might have changed from your previous build environment. There were changes in ld() between the two version your cite, including the default execution of a 64-bit version of ld() regardless of the object being built. Perhaps there's now a timing difference between the person manipulating viewer-pangox.o and the instant that ld() tries to processes this file ??? -- Rod.