On 08/01/2013 12:18 PM, Amit Saha wrote:
That said, I resorted to static because of lack of being able to find
a simple
way to find the shared libraries that lshw would be using along with their paths.
ldd gives this:
$ ldd /usr/sbin/lshw
linux-vdso.so.1 => (0x00007fff8bdaf000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x000000360e400000)
libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x0000003631600000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x000000360ec00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000360d800000)
libc.so.6 => /lib64/libc.so.6 (0x000000360c000000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000360cc00000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000360c800000)
libm.so.6 => /lib64/libm.so.6 (0x000000360c400000)
/lib64/ld-linux-x86-64.so.2 (0x000000360bc00000)
awk won't work here, since the lines vary in their fields.
ldd has a verbose flag (-v) which does spit out complete paths of the shared
libraries, but it is not very friendly for machine reading.
So, if there is a simple and sure shot way to find the shared libraries
along with their paths, setting them up in chroot is not a problem.
Try this:
$ ldd -v /sbin/lshw | grep '=>[^(]*$' | cut '-d ' -f4 | sort -u
/lib64/ld-linux-x86-64.so.2
/lib64/libc.so.6
/lib64/libdl.so.2
/lib64/libgcc_s.so.1
/lib64/libm.so.6
/lib64/libpthread.so.0
/lib64/libresolv.so.2
/lib64/libstdc++.so.6
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (
http://beaker-project.org/)