SummaryBy 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.0ProblemsProblem 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
SolutionsProblem 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.aProblem 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*
|
Sign in to add a comment
