issue building 1.8.3 on Solaris

[Tom Yu]

Will Fiveash <will.fiveash at oracle.com> writes:

> When I try to build the MIT krb 1.8.3 source tarball on a Solaris
> (current internal release) system I see this error early on:
>
> set -x; objlist=`set -x && perl -p -e 'BEGIN { $SIG{__WARN__} = sub {die @_} }; $e=$ARGV; $e =~ s/OBJS\...$//; s/^/ /; s/ $//; s/ / $e/g;' OBJS.SH` && gcc -g -shared -h libkrb5support.so.0 -o libkrb5support.so.0.1 $objlist -R/pool/willf/src/kerberos/mit/krb5-1.8.3_bld/Inst/lib  -lresolv -lsocket -lnsl    
> + set -x
> + perl -p -e 'BEGIN { $SIG{__WARN__} = sub {die @_} }; $e=$ARGV; $e =~ s/OBJS\...$//; s/^/ /; s/ $//; s/ / $e/g;' OBJS.SH
> + objlist=' threads.so init-addrinfo.so plugins.so errors.so k5buf.so gmt_mktime.so fake-addrinfo.so utf8.so utf8_conv.so zap.so'
> + gcc -g -shared -h libkrb5support.so.0 -o libkrb5support.so.0.1 threads.so init-addrinfo.so plugins.so errors.so k5buf.so gmt_mktime.so fake-addrinfo.so utf8.so utf8_conv.so zap.so -R/pool/willf/src/kerberos/mit/krb5-1.8.3_bld/Inst/lib -lresolv -lsocket -lnsl
> gcc: plugins.so: No such file or directory
> gmake[2]: *** [libkrb5support.so.0.1] Error 1
> gmake[2]: Leaving directory `/pool/willf/src/kerberos/mit/krb5-1.8.3_bld/util/support'
> gmake[1]: *** [all-recurse] Error 1
> gmake[1]: Leaving directory `/pool/willf/src/kerberos/mit/krb5-1.8.3_bld/util'
> gmake: *** [all-recurse] Error 1
>
> Note, I'm using the same config I've used to successfully build a svn
> co'ed version of the krb5-1-8 branch with:
>
>     r24461 | tlyu | 2010-10-15 16:42:29 -0500 (Fri, 15 Oct 2010) | 18 lines
>
>     ticket: 6790
>     target_version: 1.8.4
>     version_fixed: 1.8.4
>     status: resolved
>
>     pull up r24370 from trunk
>
> at the top.  Is this known or should I open a ticket?

I recently successfully built the 1.8.3 snapshot on Solaris 10.  Is
the error consistently occurring?

> Here is the full output of gmake -j 10 after I run configure:

[...]

Do you have the same problem if you don't use the "-j" option?  There
might be some kind of race condition, but from looking at the
Makefile, there's no obvious way a race can occur unless the
dependency analysis of parallel make is somehow broken.