Re: Shlib major bumps and UPDATE builds

[christos%astron.com@localhost (Christos Zoulas)]

In article <20090114.162336.39172428.he%uninett.no@localhost>,
Havard Eidnes  <he%NetBSD.org@localhost> wrote:
>OK,
>
>maybe my build host is too slow, but I continue to do UPDATE
>builds of NetBSD-current.  This flagged a problem when Christos
>recently bumped the major version of a number of our shared
>libraries.  In short, some applications ended up linking the old
>version of the shared libraries, resulting in warnings which are
>transformed into errors by the use of -Werror for our in-tree
>code.
>
>Some digging with "readelf -d" revealed that some of the shared
>libraries the application linked with had a NEEDED attribute
>which pointed to a shared library with a now old major number.
>
>I've finally found out what causes this, and it is the way we
>link our shared libraries.  As an example I use lib/libdns, where
>a MAKEVERBOSE=2 build resulted in:
>
>/u/build/HEAD/tools/sgimips/bin/mipseb--netbsd-gcc  -Wl,-nostdlib
>-B/u/build/HEAD/dest/sgimips/usr/lib/
>-B/u/build/HEAD/dest/sgimips/usr/lib/  
>-Wl,-rpath-link,/u/build/HEAD/dest/sgimips/lib:/u/build/HEAD/dest/sgimips/usr/lib
>  -L/u/build/HEAD/dest/sgimips/lib  -Wl,-x -shared
>-Wl,-soname,libdns.so.2 -Wl,--warn-shared-textrel -o libdns.so.2.0 
>-Wl,--whole-archive libdns.a  -Wl,--no-whole-archive 
>-L/u/build/HEAD/obj/sgimips/lib/libpthread -lpthread
>-L/u/build/HEAD/obj/sgimips/lib/libcrypto -lcrypto  -Wl,--fatal-warnings
>-L/u/build/HEAD/dest/sgimips/usr/lib
>
>You will note that -L${DESTDIR}/usr/lib and -L${DESTDIR}/lib
>comes before the shared libraries it wants to use, and even
>though care is taken to point to the OBJDIRS of those shared
>libraries, the previous -L.../usr/lib and -L.../lib will override
>those directories if the shared library is already installed in
>DESTDIR, as it typically will be with an UPDATE build.
>
>So... Because the shared libraries with the new major numbers
>have not been installed at this point in the build process
>(typically the "build all the libraries" phase), the shared
>library linking command above will pick up the shared libraries
>with the old major numbers from DESTDIR, causing conflicts/errors
>when applications are linked later on (I saw it with
>external/bsd/am-utils in my builds).
>
>In my case, I also wanted to easily trigger a rebuild of my
>shared libraries (without cleaning them...) so I ended up with
>the following local patch in my bsd.lib.mk file:

Good catch! I saw that too. Luke is the person to ask if your change
is correct.

christos