Code
Summary
By default, the bzip2(1), gzip(1), and progress(1) binaries are located in /usr/bin. By default they dynamic linked against /usr/bin/libz.so.0.1 and /usr/lib/libbz2.so.1 and /usr/lib/libc.so.12
Unfortunately, /usr/lib/libz.so.1.0 is actually a symlink to /lib/libz.so.1.0 while /usr/lib/libbz2.so.1.0 is a real file.
Additionaly (netbsd-4 ex.) /usr/lib/libc.so.12 is a symlink /lib/libc.so.12.149 ``` $ ldd /usr/bin/gzip /usr/bin/gzip: -lz.1 => /usr/lib/libz.so.1 -lbz2.1 => /usr/lib/libbz2.so.1 -lc.12 => /usr/lib/libc.so.12
$ ldd /usr/bin/bzip2 /usr/bin/bzip2: -lbz2.1 => /usr/lib/libbz2.so.1 -lc.12 => /usr/lib/libc.so.12
$ ls -al /usr/lib/libbbz* -r--r--r-- 1 root wheel 63306 Feb 16 14:27 /usr/lib/libbz2.a lrwxr-xr-x 1 root wheel 13 Feb 16 14:35 /usr/lib/libbz2.so@ -> libbz2.so.1.0 lrwxr-xr-x 1 root wheel 13 Feb 16 14:35 /usr/lib/libbz2.so.1@ -> libbz2.so.1.0 -r--r--r-- 1 root wheel 65115 Feb 16 14:27 /usr/lib/libbz2.so.1.0 -r--r--r-- 1 root wheel 64202 Feb 16 14:27 /usr/lib/libbz2_p.a -r--r--r-- 1 root wheel 67870 Feb 16 14:27 /usr/lib/libbz2_pic.a
$ ls -al /usr/lib/libz* -r--r--r-- 1 root wheel 74084 Feb 16 14:28 /usr/lib/libz.a lrwxr-xr-x 1 root wheel 21 Feb 16 14:35 /usr/lib/libz.so@ -> ../../lib/libz.so.1.0 lrwxr-xr-x 1 root wheel 21 Feb 16 14:35 /usr/lib/libz.so.1@ -> ../../lib/libz.so.1.0 lrwxr-xr-x 1 root wheel 21 Feb 16 14:35 /usr/lib/libz.so.1.0@ -> ../../lib/libz.so.1.0 -r--r--r-- 1 root wheel 77184 Feb 16 14:28 /usr/lib/libz_p.a -r--r--r-- 1 root wheel 79320 Feb 16 14:28 /usr/lib/libz_pic.a
$ ls /lib/libz.so* lrwxr-xr-x 1 root wheel 11 Feb 16 14:35 /lib/libz.so@ -> libz.so.1.0 lrwxr-xr-x 1 root wheel 11 Feb 16 14:35 /lib/libz.so.1@ -> libz.so.1.0 -r--r--r-- 1 root wheel 71752 Feb 16 14:28 /lib/libz.so.1.0 ```
Problems
Problem 1: /usr/bin/gzip and /usr/bin/bzip2 must be moved into /bin so that
they can be exec()'d by pax(1) during rc(8).
Problem 2: If the binaries are moved from /usr/bin to /bin, the flist
mechansism will "miss" them when generating release tarballs
Problem 3: The new binaries must link against /bin/libc, /lib/libz, and /lib/libbz
direct instead of their counterparts in /usr/lib/
Problem 4: The binaries bzip2 library cannot be a symlink from /lib/ to /usr/lib,
instead the actual binary must be located in /lib and an optional symlink from /usr/lib to /lib can exist for compatability. This will make it like libz.
Problem 5: The new libraries build and installed into /lib instead of /usr/lib,
the flist mechanism will "miss" them when generating release tarballs
Problem 6: /usr/bin/progress must be available as well. It must be located in
/bin and must be linked against /lib/libc instead of /usr/lib/libc
Solutions
Problem 1 & 2 - Solution
The binaries must be manually copied from $DESTDIR-DATE_CODE to $DSTDIR/bin where the base.tgz and etc.tgz release binary tarball sets are extracted
Proposed Solution: The flists could be modified, but that's on ongoing local working copy CVS conflict that could be dangerous. Perhaps conditional'izing in the flists using MK_{FLAG}_
Problem 3 - Solution
Setting the following:
SHLINKDIR= /libexec SHLIBDIR= /libsrc/usr.bin/progress/Makefile +and src/usr.bin/gzip/Makefile +
and src/usr.bin/bzip2/Makefile
in:
Will cause the binaries to link against /lib instead of /usr/lib, however the install-path for the binaries will remain unchanged.
/home/nbsd/dst.i386/20070304-2031EST/usr/bin/bzip2: -lbz2.1 => /lib/libbz2.so.1 -lc.12 => /lib/libc.so.12
Problem 4 - Solution:
Setting the following:
SHLINKDIR= /libexec SHLIBDIR= /libin:src/lib/libbz2/Makefile
Will cause libbz2 to install into /lib instead of /usr/lib. /usr/lib will receive the appropriate symbolic links:
$ cd foo/dst.i386/${DATECODE}/usr/lib/
$ ls -al lib{,b}z*
-r--r--r-- 1 root wheel 57538 Mar 5 00:06 libbz2.a
lrwxr-xr-x 1 root wheel 18 Mar 5 00:06 libbz2.so@ -> /lib/libbz2.so.1.0
lrwxr-xr-x 1 root wheel 18 Mar 5 00:06 libbz2.so.1@ -> /lib/libbz2.so.1.0
lrwxr-xr-x 1 root wheel 18 Mar 5 00:06 libbz2.so.1.0@ -> /lib/libbz2.so.1.0
-r--r--r-- 1 root wheel 59606 Mar 5 00:06 libbz2_p.a
-r--r--r-- 1 root wheel 63740 Mar 5 00:06 libbz2_pic.a
-r--r--r-- 1 root wheel 61480 Mar 5 00:07 libz.a
lrwxr-xr-x 1 root wheel 16 Mar 5 00:07 libz.so@ -> /lib/libz.so.0.4
lrwxr-xr-x 1 root wheel 16 Mar 5 00:07 libz.so.0@ -> /lib/libz.so.0.4
lrwxr-xr-x 1 root wheel 16 Mar 5 00:07 libz.so.0.4@ -> /lib/libz.so.0.4
-r--r--r-- 1 root wheel 65236 Mar 5 00:07 libz_p.a
-r--r--r-- 1 root wheel 66242 Mar 5 00:07 libz_pic.a
Problem 5 - Solution
The libraries must be manually copied from $DESTDIR-DATE_CODE to $DSTDIR/lib where the base.tgz and etc.tgz release binary tarball sets are extracted
Proposed Solution: The flists could be modified, but that's on ongoing local working copy CVS conflict that could be dangerous. Perhaps conditional'izing in the flists using mk.conf(5) flags that could be submitted upstream.
Problem 6 - Solution
Partially solved by Solution #3. Manual copy required.
An outline of manual steps
```
cd $src_dir
./build.sh -T tool.i386/${datecode} -D dst.i386/${datecode} \
-R rel.i386/${relcode} -O obj.i386/${datecode} release
mkdir dstdir_extr_pruned && cd $!
pax -r -pe -z -f rel.i386/${relcode}/i386/binary/sets/base.tgz
pax -r -pe -z -f rel.i386/${relcode}/i386/binary/sets/etc.tgz
du -hs .
56m .
cd foo/dst.i386/${DATECODE}/lib && pax -rw -v -pe libbz2* foo/dstdir_extr_pruned/lib && cd -
cd foo/dst.i386/${DATECODE}/usr/bin && pax -rw -v -pe progress bzip2 gzip foo/dstdir_extr_pruned/bin && cd -
cd .. && ldd ./bin/zip ./bin/progress && ls -alF ./lib{,/usr}/lib*z*
```
For example:
``` export DSTDIR_TMP=/home/nbsd/dstdir export relcode=20070304-2031EST
cd $DSTDIR_TMP pax -r -pe -z -f /home/nbsd/rel.i386/${relcode}/i386/binary/sets/base.tgz pax -r -pe -z -f /home/nbsd/rel.i386/${relcode}/i386/binary/sets/etc.tgz du -hs .
cd /home/nbsd/dst.i386/${relcode}/lib && pax -rw -v -pe libbz2* ${DSTDIR_TMP}/lib && cd - cd /home/nbsd/dst.i386/${relcode}/usr/bin && pax -rw -v -pe progress bzip2 gzip ${DSTDIR_TMP}/bin && cd - cd ${DSTDIR_TMP} && ldd ./bin/zip ./bin/progress && ls -alF ./lib{,/usr}/lib*z* ```