Re: stale base libraries v. freshly-built packages

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

On Fri, Nov 02, 2012 at 10:43:41AM -0500, John D. Baker wrote:
 > >wouldn't work due to being explicitly linked against an older version
 > >of some shared libraries (e.g., libssl.so.9) or a library that is no
 > >longer part of the distribution (e.g., libexecinfo.so.x.y).
 > 
 > The primary issue that concerned me was that the "/usr/lib/libssl.so"
 > symbolic link pointed to "libssl.so.9.0" which didn't exist.  Even more
 > troubling was that although the DESTDIR of my build tree had the correct
 > target ("libssl.so.10.0"), the ".../etc/mtree/set.base" file showed the
 > stale target and the distribution set was created using the stale target.
 > 
 > A simple non-update build was insufficient to correct the inconsistency.
 > After nuking my build tree from the top level (the only way to be sure)
 > the subsequent build showed set lists and file names finally to agree,
 > using "libssl.so.10.0".
 > 
 > (This could, of course apply to any other shared library, it's just
 > libssl that made itself conspicuous this time.)

From UPDATING:

20120726:
        The update of OpenSSL requires cleaning both the OpenSSL build
        directory and DESTDIR.  *Even non-update builds require cleaning
        DESTDIR.* Builds done without taking these steps may fail, or in
        some cases may succeed and install broken OpenSSL libraries that
        cause third-party software to link incorrectly and/or crash.

You're not the only one to have tripped on this.

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