[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