Member Avatar for i686-linux

I get this error message now when running the command 'strings' on any file. obviously I have the command 'ls' in my $PATH, so that isn't the issue. I haven't made any recent changes to anything except for a GTK upgrade to 2.4.0. 'strings' is obviously not dependant on GTK at all, so this isn't the issue. I noticed this about a week ago, but don't use the command 'strings' day to day so don't know when it actually started happening. Anyone seen this before?

Slackware 9.1
Kernel 2.4.25

If you need anymore info than that, let me know.

Thanks!

  • 2 Contributors
  • 4 Replies
  • 3K Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by alc6379

Dani AI

Generated

Good instincts from . The message fopen: No such file or directory is produced by the program calling the C library to open a path and getting ENOENT. If it happens for every target you try, suspect the strings binary itself (wrong architecture, corruption, or an odd static build) rather than the input file. strings is part of GNU binutils, so verifying how that binary is built is the right place to start. Also remember that ldd only reports dependencies for dynamically linked objects; a static strings will not show any shared libs, and ldconfig only updates the cache used by the dynamic loader. (sourceware.org, man7.org)

Quick triage that complements what already tried:

# 1) Make sure you are running the expected binary
type -a strings

# 2) Check for an ELF interpreter (dynamic loader) segment
readelf -lW "$(command -v strings)" | grep -i interp

# 3) Confirm static vs dynamic
file -L "$(command -v strings)"

# 4) See exactly what path open() is failing on
strace -o /tmp/strings.trace -f -e openat,stat strings /bin/ls
tail -n +20 /tmp/strings.trace | sed -n '1,20p'

If step 2 shows no INTERP segment and step 3 says “statically linked,” you are not using the dynamic loader; step 4 will tell you which open attempt is failing. (man7.org, man7.org)

What ultimately fixed it for (reinstalling/rebuilding binutils so strings is dynamically linked) is a solid path forward when a stale or broken static binary is to blame. If you keep a second copy as suggested, be deliberate about PATH ordering to avoid unknowingly shadowing the distro’s tool. In general, prefer a dynamically linked strings so updates to the loader and libraries are picked up automatically; static binaries bypass the dynamic loader and won’t benefit from ldconfig. (man7.org)

Recommended Answers

All 4 Replies

Member Avatar for alc6379

You've provided a good bit of info already. Did the command work before? It could be that a shared lib or something was changed since the last time you used that command.

Does it work as the root user? From the sounds of the error, it seems like the shell is trying to look for fopen. That's kind of odd. What little C programming I know tells me that fopen is a function withing the stdio.h library, not a function. It could be maybe you need to run ldconfig or something. Either that, or the fopen function isn't finding some file or something. Try running alias and see if strings is aliased to some other command, perhaps.

Member Avatar for i686-linux

Thanks for your advice! Unfortunately... it isn't aliased to anything, I run ldconfig at every boot, and every time I install anything, so that was of no help. I did try this though:

::[brandon@moonshine][~]::ldd `which strings`
not a dynamic executable

That is interesting, so I tried:

::[brandon@moonshine][~]::file !$
file `which strings`
/usr/sbin/strings: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

Aha! It is statically linked! So I tried updating the Slackware package. Seems they provide an update from binutils-2. -> binutils-2.15.90.0.1.1. No luck. :(

Member Avatar for i686-linux

Not sure how slackware has binutils 2.15 if gnu doesn't have it.... anyways. Built binutils 2.14 from source, using shared libs, and bam, everything works fine now:

::[brandon@moonshine][~]::ldd `which strings`
libc.so.6 => /lib/libc.so.6 (0x4002f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Thank you alc6379 for mentioning 'ldconfig'. It reminded me to check for any shared libs it uses, which led me to seeing it is statically linked, and so on. God it's late, and been a long week. Thanks again!

commented: he seems to know what he's doing! I'm sure others will benefit from this! +22
Member Avatar for alc6379

Excellent! I wasn't sure whether the default binutils slackware provided were statically or dynamic. That's what made me think of checking out ldconfig. Here's something to think about: if you have the time, statically compile binutils. Place it in /usr/local instead of the main root, and then modify your PATH variable to look in /usr/local/sbin (or bin) before looking in /sbin or /bin. I'd be curious as to whether it mattered that it was statically or dynamically linked.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.