Up to [cvs.NetBSD.org] / src / external / bsd / openldap / lib
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
Pull up following revision(s) (requested by riastradh in ticket #356): external/bsd/libevent/lib/Makefile: revision 1.5 external/bsd/libevent/lib/Makefile.subdir: revision 1.1 crypto/external/bsd/heimdal/lib/Makefile: revision 1.3 lib/Makefile: revision 1.297 external/bsd/openldap/lib/Makefile.subdir: revision 1.1 crypto/external/bsd/netpgp/lib/Makefile.subdir: revision 1.1 crypto/external/bsd/heimdal/lib/Makefile.subdir: revision 1.1 external/bsd/elftoolchain/lib/Makefile: revision 1.3 external/bsd/atf/lib/Makefile: revision 1.3 external/bsd/openldap/lib/Makefile: revision 1.3 external/bsd/atf/lib/Makefile.subdir: revision 1.1 crypto/external/bsd/netpgp/lib/Makefile: revision 1.18 external/bsd/elftoolchain/lib/Makefile.subdir: revision 1.1 lib: Handle various external lib directories with build_install. This way, update builds track shlib major bumps correctly. For example, suppose you had built Heimdal's libkrb5.so.27 and libgssapi.so.11 linked against it, and then you updated past the recent shlib major bump raising them to libkrb5.so.28 and libgssapi.so.12. Without this change, the build will make the following sequence of targets (interleaved with some others): 1. make dependall in libkrb5 2. make dependall in libgssapi 3. make install in libkrb5 4. make install in libgssapi The existing .WAIT tags in SUBDIR ensure that (1) happens before (2) and (3) happens before (4). Unfortunately, this sequence is wrong, because it will produce the following effect: 1. make dependall in libkrb5 builds libkrb5.so.28 2. make dependall in libgssapi builds libgssapi.so.12, linked against libkrb5.so.27 3. make install in libkrb5 installs libkrb5.so.28 4. make install in libgssapi installs libgssapi.so.12 Why the out-of-date libkrb5.so.27 in step (2)? Because we just pass -L${DESTDIR}/usr/lib -lkrb5 to the linker (or the equivalent with --sysroot and implied -L/usr/lib), and ${DESTDIR}/usr/lib still has only libkrb5.so.27 by the time of step (2), not libkrb5.so.28. Now any applications that link against libkrb5.so _and_ libgssapi.so will get libkrb5.so.28 and libgssapi.so.12 -- but transitively, via libgssapi.so.12, they will also get libkrb5.so.27, which is a recipe for disaster. Splicing the Heimdal library subdirectories into lib/Makefile, as this does, ensures that we run make dependall _and_ make install in libkrb5 _before_ make dependall in libgssapi, giving the following correct sequence: 1. make dependall in libkrb5 builds libkrb5.so.28 2. make install in libkrb5 installs libkrb5.so.28 3. make dependall in libgssapi builds libgssapi.so.12, linked against libkrb5.so.28 4. make install in libgssapi installs libgssapi.so.12 Note that LIBDPLIBS isn't enough here, as implemented. LIBDPLIBS ensures that the incremental build will remake libgssapi.so. But it doesn't ensure that the new libkrb5.so.28 is available before then, so it doesn't prevent this problem. We use the same mechanism for crypto/external/bsd/openssl/lib already; this just extends it to other external library collections. As an alternative, in principle perhaps we could teach LIBDPLIBS to ensure that libkrb5.so comes out of the libkrb5 objdir, and not out of ${DESTDIR}/usr/lib. But that requires some work to make happen, and make it reliable, whereas this approach we've already confirmed works without other adverse consequences (besides leaving grody-looking mechanism lying around) for the libcrypto major bump already. We need to get this pulled up to the branch so all the other major bumps it required are handled correctly by update builds.
file Makefile.subdir was added on branch netbsd-10 on 2023-09-08 09:03:54 +0000
lib: Handle various external lib directories with build_install. This way, update builds track shlib major bumps correctly. For example, suppose you had built Heimdal's libkrb5.so.27 and libgssapi.so.11 linked against it, and then you updated past the recent shlib major bump raising them to libkrb5.so.28 and libgssapi.so.12. Without this change, the build will make the following sequence of targets (interleaved with some others): 1. make dependall in libkrb5 2. make dependall in libgssapi 3. make install in libkrb5 4. make install in libgssapi The existing .WAIT tags in SUBDIR ensure that (1) happens before (2) and (3) happens before (4). Unfortunately, this sequence is wrong, because it will produce the following effect: 1. make dependall in libkrb5 builds libkrb5.so.28 2. make dependall in libgssapi builds libgssapi.so.12, linked against libkrb5.so.27 3. make install in libkrb5 installs libkrb5.so.28 4. make install in libgssapi installs libgssapi.so.12 Why the out-of-date libkrb5.so.27 in step (2)? Because we just pass -L${DESTDIR}/usr/lib -lkrb5 to the linker (or the equivalent with --sysroot and implied -L/usr/lib), and ${DESTDIR}/usr/lib still has only libkrb5.so.27 by the time of step (2), not libkrb5.so.28. Now any applications that link against libkrb5.so _and_ libgssapi.so will get libkrb5.so.28 and libgssapi.so.12 -- but transitively, via libgssapi.so.12, they will also get libkrb5.so.27, which is a recipe for disaster. Splicing the Heimdal library subdirectories into lib/Makefile, as this does, ensures that we run make dependall _and_ make install in libkrb5 _before_ make dependall in libgssapi, giving the following correct sequence: 1. make dependall in libkrb5 builds libkrb5.so.28 2. make install in libkrb5 installs libkrb5.so.28 3. make dependall in libgssapi builds libgssapi.so.12, linked against libkrb5.so.28 4. make install in libgssapi installs libgssapi.so.12 Note that LIBDPLIBS isn't enough here, as implemented. LIBDPLIBS ensures that the incremental build will remake libgssapi.so. But it doesn't ensure that the new libkrb5.so.28 is available before then, so it doesn't prevent this problem. We use the same mechanism for crypto/external/bsd/openssl/lib already; this just extends it to other external library collections. As an alternative, in principle perhaps we could teach LIBDPLIBS to ensure that libkrb5.so comes out of the libkrb5 objdir, and not out of ${DESTDIR}/usr/lib. But that requires some work to make happen, and make it reliable, whereas this approach we've already confirmed works without other adverse consequences (besides leaving grody-looking mechanism lying around) for the libcrypto major bump already. We need to get this pulled up to the branch so all the other major bumps it required are handled correctly by update builds. XXX pullup-10