in reply to Re^2: Capture::Tiny getting stuck on ldd /proc/self/fd/1
in thread Capture::Tiny getting stuck on ldd /proc/self/fd/1

I'm running ldd on a list of paths I find to find the shared libs.

There are no shared libs in /proc. If you find any in /dev, chances are that you were hacked.

Is there a way in perl to check if path is dynamic

You could use the linux file(1) utility to check the type and look for shared object and dynamically linked in its output. I'm not aware of a perl module which provides that information.

You didn't answer the question: for what purpose? If you just want the dynamic libraries your system knows about, run ldconfig -p and parse the output. Note that most of the files it reports are symbolic links, which you might have to resolve, depending on purpose.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^4: Capture::Tiny getting stuck on ldd /proc/self/fd/1
by choroba (Cardinal) on Jun 22, 2021 at 15:17 UTC
    > I'm not aware of a perl module which provides that information.

    You can experiment with File::Type, File::LibMagic, File::MMagic, etc.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]

      These only provide the MIME type: 

      perl -MFile::MMagic -E 'say File::MMagic->new->checktype_filename(pop)
+' /usr/lib/x86_64-linux-gnu/libHalf.so.12.0.0
application/octet-stream
perl -MFile::Type -E 'say File::Type->new->checktype_filename(pop)' /u
+sr/lib/x86_64-linux-gnu/libHalf.so.12.0.0
application/x-executable-file

      [download]

      update

      File::LibMagic is more informative: 
      perl -MFile::LibMagic -E 'say File::LibMagic->new->info_from_filename(
+pop)->{description}' /usr/lib/x86_64-linux-gnu/libHalf.so.12.0.0
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically li
+nked, BuildID[sha1]=442946ad0e7c43d51d7b05c7a73e02273b9b56d2, strippe
+d

      [download]

      Thanks, choroba.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
[select]
Re^4: Capture::Tiny getting stuck on ldd /proc/self/fd/1
by ovedpo15 (Pilgrim) on Jun 22, 2021 at 13:59 UTC
    I'll try to explain what I'm trying to achieve. I have a file of paths that define my tool (all the needed paths to run my tool). I want to create a Dockerfile/Podman-file/Sing-file based on those dependencies so the container will be able to run the tool inside it. I want to find all the RPM packages of those paths. For that I use: 
    rpm -qf --queryformat "[%{NAME}]" [path]

    [download]
    But this command does not give me all the packages I need. I noticed that if I use ldd [path] to get all shared libs and then for each lib, run the above RPM command, then I'll get all the needed packages.

    So the my algorithm fow now is:
    1. Run the above RPM command on the path and find related packages.
    2. Run the ldd command on the path to find the shared libs.
    3. For each shared lib path, repeat step 1 and step 2 (because shared lib can also have shared libs).
    4. Keep track of all the paths that were already and stop once it's empty.

    The algorithm works pretty well (until I came across with this special file). That way I will find all the related RPM packages. Now the problems:
    1. I want to run step 2 only on dynamic files only (to prevent running ldd on all of the paths and it also solves /proc/self/fd/1).
    2. I'm familiar with the file command. The problem with that command is that it's output is a syntax-based. Which means that I will have something like if ($output =~ /dynamically linked/) # do stuff and if some output prints "not dynamically linked", it will be wrong. In other words, what I'm trying to say is that it's syntax-dependent.

    Do you think that I need to parse the output of file command? If so, what would be the best way to do it?
    Also ldconfig -p does not help me here since it gives me all the libs and not that are really being used.
[reply]
[d/l]
[select]
      But this command does not give me all the packages I need.

      That's because you are not querying their dependencies. Run rpm -q --requires $pkg on the packages found. This will give you the packages they depend on. Add those packages, query their dependencies, repeat and you should end up with the complete set. No need for ldd.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
[select]
        Thanks again for your reply.
        So lets take an example /usr/bin/grep. In that case I get: 
        rpm -qf --queryformat "[%{NAME}]" /usr/bin/grep
grep

        [download]
        After that, you suggested to run: 
        rpm -q --requires grep
info
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
rpmlib(PayloadIsLzma) <= 4.4.6-1

        [download]
        How to handle this output? Which lines interest me? I guess to run rpm -q --requires info and get: 
        bash
zlib
libzio
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libbz2.so.1()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libncurses.so.5()(64bit)
libz.so.1()(64bit)
libzio.so.0()(64bit)
rpmlib(PayloadIsLzma) <= 4.4.2-1

        [download]
        What should I do with other lines?
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom