17 ms·
Libtree: Turns ldd into a tree; explains why shared libraries are found or not
- jmarcher 5y agoIs there anything remotely close to this for macOS?
- diimdeep 5y agoCheck out https://github.com/kwin/macdependency https://github.com/kwin/macdependency
- joshvm 5y agoYou 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/fix_paths_mac.py https://github.com/jveitchmichaelis/deeplabel/blob/master/fi...
- agateau 5y agoNice! reminds me of copydeps (https://github.com/Genymobile/copydeps https://github.com/Genymobile/copydeps)
- khoobid_shoma 5y agoI 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 5y agoYes, I agree, this is the plan :)
- joshuaissac 5y agoOn 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.
- evol262 5y agoThis 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/3d67c4295bbe78135a4927bd1d822e04 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)
- bmn__ 5y agoThat code does not work, it won't even compile with `-Mstrict`.
- nor-and-or-not 5y ago> C++ is probably painful even statically compiled, and Go/Rust would be better What does that even mean?
- agumonkey 5y agoGot 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)
- odc 5y agoOn Linux with glibc, ldd -v will give you similar information, though less pretty of course.
- marcodiego 5y agoBeware that ldd needs to run the binary to check for dependencies. It can be a security risk to use it without a sandbox.
- touisteur 5y agoHuh, any reference about this? How much of the binary does it run?
- egberts1 5y agoSUPER GREAT for bundling software into a folder. Great for demo and standalone prototyping.
- NougatRillettes 5y agoThis is very cool!
- chjj 5y agoNow I'm wondering why ldd doesn't offer this feature in the first place.
- jcranmer 5y agoThe 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.)
- IshKebab 5y agoBecause 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.
- rerx 5y agoI 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.
- CameronNemo 5y agoSee also lddtree from pax-utils: https://cgit.gentoo.org/proj/pax-utils.git/tree/lddtree.py https://cgit.gentoo.org/proj/pax-utils.git/tree/lddtree.py
- totony 5y agohttps://github.com/gentoo/pax-utils/blob/master/lddtree.py https://github.com/gentoo/pax-utils/blob/master/lddtree.py already does this. Cool to see though, very useful
- jedbrown 5y agolddtree is much faster, but libtree has more detailed info.
- stabbles 5y agoIf you want something fast, note that (https://github.com/haampie/libtree-in-c 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'
- stabbles 5y agoThe C rewrite was released in libtree 3.0.0
- rwmj 5y agoOr 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 5y ago
- synergy20 5y agoWhat? 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 5y agoPlease 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.
- ekianjo 5y agoI took the comment as a jest.
- synergy20 5y agoIt is just a harmless joke, sorry if it offends anyone. I use a lot of rust CLI tools myself and love them. Meanwhile I also do c++ coding. they complement each other well.
- pdimitar 5y agoIf 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 5y agoI doubt that the grandparent is a Rust developer.
- jeltz 5y agoIt is a huge assumption to think the parent comment was from anyone in the Rust community. It could be a Rust hater.
- CameronNemo 5y ago
- nneonneo 5y agoAh, 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 5y agoYou'll probably want to use this: https://github.com/lucasg/Dependencies https://github.com/lucasg/Dependencies
- deleted 5y ago[deleted]