clearing DESTDIR and the openssl update

[David Holland <dholland-tech%netbsd.org@localhost>]

The problem that leads to a successful but broken build is that libssl
ends up linked to the old libcrypto instead of the new one. Then all
(or nearly all) binaries end up linked to both versions of libcrypto
and subsequent behavior is undefined.

Anyhow, I just found the bug in the makefiles that causes this.

In lib/Makefile we (now) have the following logic:

build_install:
.for group in ${SUBDIR_GROUPS}
.  if !empty(SUBDIR_GROUP.${group})
        ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${group}:C/^/dependall-/}
        ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${group}:C/^/install-/}
.  endif
.endfor

This is what's run during the lib phase of a full build. The problem
is that libcrypto and libssl do not appear separately in this file;
all that appears in this file is ../crypto/external/bsd/openssl/lib.

Therefore, during a build, what happens is... first we make dependall
in openssl/lib, which first makes libcrypto and then dutifully waits
before making libssl. Then we make install in openssl/lib, at which
point the new libcrypto is placed in $DESTDIR. Unfortunately, libssl
has at this point already been linked to the old libcrypto in
$DESTDIR; and the barrier implicit in recursing twice in the logic
pasted above is what makes the failure deterministic.

If you clean out $DESTDIR, then this can't happen. I'm not sure why
the build doesn't simply fail at this point due to there being no
libcrypto to link to; maybe it's capable of finding the lib in the
libcrypto build dir but prefers the one in $DESTDIR if present. Or
maybe it just charges ahead; ELF toolchains believe by default that
you don't need to resolve symbols successfully when building libraries
and I'm not sure how thoroughly we disable that misfeature.

Anyway, either lib/Makefile needs to know about the various openssl
libraries individually, or this dodgy build_install rule needs to be
fixed/removed. Why does it have its own private recursion logic again?

-- 
David A. Holland
dholland%netbsd.org@localhost