[Beaker-devel] Test framework for lshw
Nick Coghlan
ncoghlan at redhat.com
Thu Aug 1 03:24:36 UTC 2013
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/)
More information about the Beaker-devel
mailing list