💾 Archived View for dioskouroi.xyz › thread › 29413753 captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Libtree: Turns ldd into a tree; explains why shared libraries are found or not

Author: fanf2

Score: 270

Comments: 48

Date: 2021-12-02 08:24:32

Web Link

________________________________________________________________________________

agumonkey wrote at 2021-12-04 11:32:17:

Got me to learn that vim requires libcanberra requires libvorbisfile ... libogg

./libtree_x86_64 $(which vim)
    vim
    ├── libtinfo.so.6 [ld.so.conf]
    ├── libselinux.so.1 [ld.so.conf]
    │   └── libpcre2-8.so.0 [ld.so.conf]
    ├── libcanberra.so.0 [ld.so.conf]
    │   ├── libvorbisfile.so.3 [ld.so.conf]
    │   │   ├── libvorbis.so.0 [ld.so.conf]
    │   │   │   └── libogg.so.0 [ld.so.conf]
    │   │   └── libogg.so.0 (collapsed) [ld.so.conf]
    │   ├── libtdb.so.1 [ld.so.conf]
    │   └── libltdl.so.7 [ld.so.conf]
    ├── libacl.so.1 [ld.so.conf]
    ├── libgpm.so.2 [ld.so.conf]
    └── libpython3.8.so.1.0 [ld.so.conf]

surprising

(and super neat tool, even though people mentionned ldd could do part of it)

totony wrote at 2021-12-04 01:28:34:

https://github.com/gentoo/pax-utils/blob/master/lddtree.py

already does this. Cool to see though, very useful

totony wrote at 2021-12-04 01:36:37:

Seems like it uses ELF parsing, I wonder if it works on non-native binaries (lddtree does not)

jedbrown wrote at 2021-12-04 05:49:19:

lddtree is much faster, but libtree has more detailed info.

stabbles wrote at 2021-12-04 15:46:36:

If you want something fast, note that (

https://github.com/haampie/libtree-in-c

) is currently faster than ldd:

    libtree-in-c $ make CC=musl-gcc CFLAGS="-Os -s -static"
    musl-gcc -Os -s -static -c libtree.c
    musl-gcc -Os -s -static -o libtree libtree.o

    libtree-in-c $ hyperfine 'ldd libLLVM.so' './libtree ./libLLVM.so'
    Benchmark #1: ldd libLLVM.so
    Time (mean ± σ):       6.1 ms ±   0.3 ms    [User: 5.2 ms, System: 1.2 ms]
    Range (min … max):     5.3 ms …   8.1 ms    348 runs

    Benchmark #2: ./libtree ./libLLVM.so
    Time (mean ± σ):       2.4 ms ±   0.4 ms    [User: 1.2 ms, System: 1.2 ms]
    Range (min … max):     1.7 ms …   3.4 ms    840 runs

    Warning: Command took less than 5 ms to complete. Results might be inaccurate.
    
    Summary
    './libtree ./libLLVM.so' ran
        2.54 ± 0.43 times faster than 'ldd libLLVM.so'

rwmj wrote at 2021-12-04 08:54:44:

Or even more basic:

  $ eu-readelf -d /bin/ls | grep NEEDED
  NEEDED            Shared library: [libselinux.so.1]
  NEEDED            Shared library: [libcap.so.2]
  NEEDED            Shared library: [libc.so.6]

Of course the trick is doing it recursively and having nice output.

IshKebab wrote at 2021-12-04 09:20:26:

That's not the same. ldd actually finds the libraries and their dependencies.

rwmj wrote at 2021-12-04 13:43:47:

Of course. I'm just pointing out how the source data is encoded in the ELF file. As I said in the comment there is much value in the tools that take this data and the locations of the libraries and build up a nice tree.

joshuaissac wrote at 2021-12-04 10:29:46:

On Solaris, you can get the tree with:

ldd -s <binary_name>

It gives you the dependency tree, tells you the search paths it used for each dependency in the tree (LD_LIBRARY_PATH, the RUNPATH for the specific binary, and ld.config file), and the reason it rejected any files it did find, e.g. missing symbol version.

marcodiego wrote at 2021-12-04 14:15:55:

Beware that ldd needs to run the binary to check for dependencies. It can be a security risk to use it without a sandbox.

touisteur wrote at 2021-12-04 19:27:58:

Huh, any reference about this? How much of the binary does it run?

CameronNemo wrote at 2021-12-04 01:27:03:

nneonneo wrote at 2021-12-04 01:50:54:

Ah, excellent. Windows has Dependency Walker, which was always useful for tracking down weird DLL errors - glad to see something like this for Linux too.

tigerlily wrote at 2021-12-04 02:58:46:

You'll probably want to use this:

https://github.com/lucasg/Dependencies

chjj wrote at 2021-12-04 01:05:31:

Now I'm wondering why ldd doesn't offer this feature in the first place.

jcranmer wrote at 2021-12-04 05:43:27:

The output format isn't nice, but LD_DEBUG=files will tell you which file requested each library.

(The LD_DEBUG environment option is a useful tool in the rare circumstances when you really, really need help debugging the library loading process.)

sillysaurusx wrote at 2021-12-04 01:15:57:

Trees are quite hard to do well in a CLI app. Everything from the Unicode drawing to the sizing to the color choices. This one looks great.

monocasa wrote at 2021-12-04 01:43:42:

It's not like ldd is a paragon of cli design to begin with. Indentation isn't difficult, you just pass in the indentation level and increment as needed as you recursively walk the tree.

chjj wrote at 2021-12-04 01:20:57:

Unicode isn't necessary if the terminal supports ACS.

monocasa wrote at 2021-12-04 01:40:45:

You can do a passable job with just + - and | if you need to. Have done that for a ucontroller's cli.

eklitzke wrote at 2021-12-04 01:24:27:

What is ACS?

chjj wrote at 2021-12-04 01:27:23:

Most terminals (even non-unicode-capable ones) offer a feature to switch into "alt charset mode" which provides glyphs for drawing lines.

sillysaurusx wrote at 2021-12-04 02:06:38:

Thanks! It’s getting rare to learn about a feature that surprises me, but I had no idea about this.

jldugger wrote at 2021-12-04 05:25:44:

just saying: pstree figured it out

IshKebab wrote at 2021-12-04 09:34:21:

Because it's a core Linux tool and they basically never change. Why doesn't ps have an option to only show your processes? Why doesn't objdump tell you what all the symbol flags mean so I don't have to look them up on StackOverflow every time?

I'm sure there are better examples but there are a ton of ways the usability of the Linux CLI could be improved but nobody is going to bother because everything's written in horrible C and to contribute you'd have to join some mailing list and convince a load of stuck-in-the-mud it-was-hard-for-me-so-I'm-not-making-it-easy-for-you neckbeards that your change won't break compatibility on a PDP-11, and anyway what's the problem? You just run `ps -fu $(whoami) | less`. Easy.

Way easier and more fun to write a new tool.

teddyh wrote at 2021-12-04 11:30:03:

> _Why doesn't ps have an option to only show your processes?_

Because that is the default behavior.

IshKebab wrote at 2021-12-04 17:36:22:

No, by default it shows you processes for the current terminal.

rerx wrote at 2021-12-04 10:20:12:

I agree that the interface of ps is awful with its two conflicting ways to define options, but `ps u` does show all your processes on Linux. I usually type `ps fux` to get a nice tree. Sadly that's Linux-specific and doesn't work on the Mac.

IshKebab wrote at 2021-12-04 17:41:00:

`ps u` just changes the output format. It's not the same as `ps -u $(whoami)`

khoobid_shoma wrote at 2021-12-04 13:18:47:

I like your other implementation more, libtree-in-c. Actually, I think it is better to exchange the names and let's libtree be in C and the other one be called libtree-in-cpp or libtree-in-c++.

stabbles wrote at 2021-12-04 15:39:11:

Yes, I agree, this is the plan :)

jmarcher wrote at 2021-12-04 03:50:03:

Is there anything remotely close to this for macOS?

joshvm wrote at 2021-12-04 04:04:52:

You can use things like `otool` which will tell you what path to the library the binary is expecting. Here's a tool I wrote to fix paths recursively for an application, for example:

https://github.com/jveitchmichaelis/deeplabel/blob/master/fi...

diimdeep wrote at 2021-12-04 06:35:20:

Check out

https://github.com/kwin/macdependency

agateau wrote at 2021-12-04 08:56:01:

Nice! reminds me of copydeps (

https://github.com/Genymobile/copydeps

)

odc wrote at 2021-12-04 13:55:03:

On Linux with glibc, ldd -v will give you similar information, though less pretty of course.

NougatRillettes wrote at 2021-12-04 01:00:31:

This is very cool!

synergy20 wrote at 2021-12-04 01:37:48:

What? new CLI utilities are not in rust?

And yes it's very useful, can do more than pax-util's lddtree(libtree can help packaging your binary with all its libraries in one package), just installed and looks great.

gonzus wrote at 2021-12-04 09:30:19:

Please don't do this. There is nothing that says CLI utilities (or any other programs for that matter) HAVE to be written in Rust.

This type of comment puts me off Rust, slowly but surely.

jeltz wrote at 2021-12-04 13:06:14:

It is a huge assumption to think the parent comment was from anyone in the Rust community. It could be a Rust hater.

ekianjo wrote at 2021-12-04 10:35:43:

I took the comment as a jest.

pdimitar wrote at 2021-12-04 10:52:14:

If some bad apples in a community (every community has them) can make you give up on a technology then you never actually considered it in the first place.

GrayShade wrote at 2021-12-04 11:48:17:

I doubt that the grandparent is a Rust developer.

CameronNemo wrote at 2021-12-04 01:42:42:

Where are you seeing rust? Or is this just tongue in cheek?

synergy20 wrote at 2021-12-04 01:58:40:

sorry, typo, forgot 'not' there

evol262 wrote at 2021-12-04 10:58:09:

This is fine. It's a great beginner project -- C++ is probably painful even statically compiled, and Go/Rust would be better.

But you may as well make it a little smarter. Over a decade ago, this utility could be done ad-hoc in 100 lines of Perl (including spacing and comments), and that includes "try to see if yum on RHEL6 knows where to find the missing dep, build a list, and prompt to install":

https://gist.github.com/evol262/3d67c4295bbe78135a4927bd1d82...

It would be a fun project for you to try to do this with dpkg/pacman/dnf (which is basically the same as yum for syntax, just that you're not gonna be a sysadmin hacking out Perl to solve a problem)

nor-and-or-not wrote at 2021-12-04 12:20:38:

> C++ is probably painful even statically compiled, and Go/Rust would be better

What does that even mean?

bmn__ wrote at 2021-12-04 14:31:32:

That code does not work, it won't even compile with `-Mstrict`.