7

I downloaded a Chromium snapshot and unzipped it, like this:

michael@ubuntu:/opt/chrome-linux$ ls
chrome                  libffmpegsumo.so                nacl_irt_x86_32.nexe
chrome.1                libppGoogleNaClPluginChrome.so  product_logo_48.png
chrome_100_percent.pak  locales                         resources
chrome.pak              nacl_helper                     resources.pak
chrome_sandbox          nacl_helper_bootstrap           xdg-mime
chrome-wrapper          nacl_irt_srpc_x86_32.nexe       xdg-settings

But when I try to run chrome, it isn't there...

michael@ubuntu:/opt/chrome-linux$ ./chrome
bash: ./chrome: No such file or directory

Does anyone know why it won't open? Running Xubuntu 12.10 AMD64.

michael@ubuntu:/opt/chrome-linux$ ldd /opt/chrome-linux/* | grep -i "not found"
ldd: /opt/chrome-linux/locales: not regular file
ldd: /opt/chrome-linux/resources: not regular file
Organic Marble
  • 23,641
  • 15
  • 70
  • 122
Michael
  • 73

3 Answers3

8

You're missing 32-bit support. Install libc6:i386, i.e. the 32-bit base library package, and all the other 32-bit libraries that Chrome needs (it's likely to be close to the dependencies of the Chromium package).

When you fail to execute a file that depends on a “loader”, the error you get may refer to the loader rather than the file you're executing.

  • The loader of a dynamically-linked native executable is the part of the system that's responsible for loading dynamic libraries. It's something like /lib/ld.so or /lib/ld-linux.so.2, and should be an executable file.
  • The loader of a script is the program mentioned on the shebang line, e.g. /bin/sh for a script that begins with #!/bin/sh.

The error message is rather misleading in not indicating that the loader is the problem. Unfortunately, fixing this would be hard because the kernel interface only has room for reporting a numeric error code, not for also indicating that the error in fact concerns a different file.

Once you install the 32-bit dynamic loader /lib/ld-linux.so.2, which is in the libc6:i386 package, you will at least get a non-misleading error message telling you of the other missing libraries.

1

The fastest way to get to Gilles' solution is to install ia32-libs-multiarch. While this does pull in a lot of packages, it saves you the time to figure out all the different dependencies.

iGadget
  • 873
  • Yes, basically, this is just a metapackage depending on the same (or similar) set of libraries that were shipped with the ia32-libs package before the Multiarch change. It's fair quick solution if you don't mind the big load of 32-bit packages to be installed. I'll integrate this in my answer of another question. :) – gertvdijk Jan 24 '13 at 13:13
  • The problem is that the ia32-libs package is removed since Ubuntu 13.10. – c_korn Oct 12 '13 at 15:19
-1

First, check for missing libraries with ldd on the executable:

ldd "$(command -v lmutil)"
linux-gate.so.1 (0xf7ee3000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7ed0000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7dc9000)
libgcc_s.so.1 => not found
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7b6a000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7b65000)
/lib/ld-lsb.so.3 => /lib/ld-linux.so.2 (0xf7ee5000)

Here, it's obvious that we are missing a library. Installing libgcc_s.so.1 fixed that. Now ldd looks entirely happy:

linux-gate.so.1 (0xf7ee3000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7ed0000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7dc9000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7d9d000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7b6a000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7b65000)
/lib/ld-lsb.so.3 => /lib/ld-linux.so.2 (0xf7ee5000)

However, that was just the beginning in my case. The symptom was still the same. Both strace and gdb would tell the same story:

strace "$(command -v lmutil)"
execve(/* 26 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

Next, don't trust ldd. The file /lib/ld-lsb.so.3 is actually missing!

Moreover, no package on Ubuntu 23.04 provides it (as shown by an apt-file search). Actually not on Ubuntu 22.04 either, except there, I bisected it down to the lsb-core package. It appears that even though the package does not contain the file (as shown by dpkg -L), you get it (as a symlink) when installing the package. This package does not exist on Ubuntu 23.04, though, and the lsb-base package that it has instead does not give you that symlink.

Solution:

ln -s ld-linux.so.2 /lib/ld-lsb.so.3
  • (a) this doesn't actually answer the question, since you can't say what exactly is this "missing sauce" and (b) is easy to verify is false. (docker run --rm -it --platform linux/amd64 ubuntu:22.04 sh -c 'dpkg --add-architecture i386; apt update; apt install wget:i386 file --no-install-recommends -y; file $(command -v wget); wget --version; apt-cache policy lsb-core' <= 32-bit wget runs, no lsb-core is installed) – muru Aug 16 '23 at 09:40
  • I found it. It just took me 3 days. I hope it saves 3 days for the next person that needs it. – user2394284 Aug 16 '23 at 12:50
  • Hopefully they find https://askubuntu.com/q/665846/158442 and the post linked there as well – muru Aug 16 '23 at 12:54
  • Indeed, that's exactly my problem, but the reason for my whole endeavor was that the lsb package no longer exists in Ubuntu 23.04. So that's what I started with, and that's no longer the fix. – user2394284 Aug 16 '23 at 13:13
  • You did read the other linked post? – muru Aug 16 '23 at 13:53
  • I did, but that's the 64-bit version of the problem. Anyway, it's not relevant how specific my problem was. The real lesson is how one is supposed to debug the symptom further than the two answers before, and that's my contribution. – user2394284 Aug 16 '23 at 14:24