After "emsdk activate tot" , "emcc hello.c" gives "clang: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory"

[shlomif]

After emsdk install tot and emsdk activate tot

[shlomif@telaviv1 ~]$ . ~/bin/Dev-Path-Configs-Source-Me.bash
Adding directories to PATH:
PATH += /home/shlomif/Download/unpack/prog/llvm-to-js/emsdk
PATH += /home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/upstream/emscripten
PATH += /home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/node/14.15.5_64bit/bin

Setting environment variables:
PATH = /home/shlomif/Download/unpack/prog/llvm-to-js/emsdk:/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/upstream/emscripten:/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/node/14.15.5_64bit/bin:/home/shlomif/bin:/home/shlomif/apps/perl/modules/bin:/home/shlomif/apps/perl/modules/local/bin:/home/shlomif/apps/neovim/bin:/home/shlomif/apps/fop/fop-20140425:/home/shlomif/apps/vim/bin:/home/shlomif/apps/golang/bin:/home/shlomif/.local/bin:/home/shlomif/.perl6/bin:/home/shlomif/.cargo/bin:/home/shlomif/apps/to-del-fortune--redhat/games:/home/shlomif/apps/to-del-fortune--redhat/bin:/home/shlomif/perl5/bin:/home/shlomif/apps/latemp/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/usr/games
EMSDK = /home/shlomif/Download/unpack/prog/llvm-to-js/emsdk
EM_CONFIG = /home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/.emscripten
EMSDK_NODE = /home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/node/14.15.5_64bit/bin/node
[shlomif@telaviv1 ~]$ emcc ~/progs/C/snippets/shlomif-c-snippets/hello_world.c
/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/upstream/bin/clang: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory
emcc: error: '/home/shlomif/Download/unpack/prog/llvm-to-js/emsdk/upstream/bin/clang --version' failed (returned 127)
[shlomif@telaviv1 ~]$ cat ~/progs/C/snippets/shlomif-c-snippets/hello_world.c

/*
 * The canonical Hello World program kept here to avoid code duplication
 *
 * License is the MIT/Expat license - http://opensource.org/licenses/MIT .
 * ( https://en.wikipedia.org/wiki/MIT_License ).
 */
#include <stdio.h>

int main(void)
{
    printf ("%s\n", "Hello World!");

    return 0;
}
[shlomif@telaviv1 ~]$

System:
  Host: telaviv1.shlomifish.org Kernel: 5.14.16-201.fc34.x86_64 x86_64
  bits: 64 Desktop: Xfce 4.16.0 Distro: Fedora release 34 (Thirty Four)
CPU:
  Info: Dual Core model: Intel Core i3-2100 bits: 64 type: MT MCP cache:
  L2: 3 MiB
  Speed: 3070 MHz min/max: 1600/3100 MHz Core speeds (MHz): 1: 3070
  2: 2835 3: 3076 4: 2808
Graphics:
  Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics driver: i915 v: kernel
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting
  unloaded: fbdev,vesa resolution: 1920x1080~60Hz
  OpenGL: renderer: Mesa DRI Intel HD Graphics 2000 (SNB GT1)
  v: 3.3 Mesa 21.1.8

[shlomif]

I have an update: emcc gives the same error also after emsdk activate latest.

[shlomif]

another update: seems like both versions started working after I ran sudo dnf -y install libatomic.

[sbc100]

Hmm.. this seems to be a core dependency of clang/llvm... although it looks like it wasn't always the case.

From 2.0.20:

ldd ./upstream/bin/clang
	linux-vdso.so.1 (0x00007ffc324fe000)
	libLLVM-13git.so => /usr/local/google/home/sbc/dev/wasm/emsdk/./upstream/bin/../lib/libLLVM-13git.so (0x00007f29cd81a000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f29cd7d1000)
	libclang-cpp.so.13git => /usr/local/google/home/sbc/dev/wasm/emsdk/./upstream/bin/../lib/libclang-cpp.so.13git (0x00007f29c9da8000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f29c9c63000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f29c9c49000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f29c9a84000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f29c9a77000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f29c9a71000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f29c9a54000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f29d1738000)
(reverse-i-search)`in': ldd ./upstream/b^C/clang

From 3.0.30:

$ ldd ./upstream/bin/clang
	linux-vdso.so.1 (0x00007fff4ddc8000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2e6dbe6000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2e6dbdb000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2e6dbd5000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2e6da90000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2e6da73000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2e6da59000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2e6d892000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2e6dc31000)

From 2.0.33:

$ ldd ./upstream/bin/clang
	linux-vdso.so.1 (0x00007ffc0a18f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f85241a6000)
	libclang-cpp.so.14git => /usr/local/google/home/sbc/dev/wasm/emsdk/./upstream/bin/../lib/libclang-cpp.so.14git (0x00007f85204be000)
	libLLVM-14git.so => /usr/local/google/home/sbc/dev/wasm/emsdk/./upstream/bin/../lib/libLLVM-14git.so (0x00007f851c5a9000)
	libc++.so.2 => /usr/local/google/home/sbc/dev/wasm/emsdk/./upstream/bin/../lib/libc++.so.2 (0x00007f851c2a1000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f851c15c000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f851c142000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f851bf7b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f85241f1000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f851bf70000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f851bf6a000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f851bf4d000)
	libatomic.so.1 => /usr/lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f851bf43000)

@dschuff do you know whats going on here? Looks like it changed when we started depending on our own libc++?

Should we also bundle libatomic? Or can/should we assume it to be present?

[dschuff]

Hm, yeah it looks like libatomic is a dependency of libc++ rather than directly of LLVM. I am actually quite surprised that there are any Linux distros that ship without it by default. On one hand it's not the only non-system "third party" dependency that we have (e.g. we depend on zlib), but clearly there are systems where this is a problem, so maybe we should see if there's a reasonable way to work around it. maybe libc++ can be built without that dependence, or we can link it statically, or just build it ourselves or something.

[sbc100]

@shlomif what linux distro are you using?

[dschuff]

OP says bits: 64 Desktop: Xfce 4.16.0 Distro: Fedora release 34 (Thirty Four). So not exactly a tiny niche distro.

[sbc100]

Yup, sounds like we want to link it statically if possible then.

[dschuff]

Or maybe just leave it out entirely. Poking through the libcxx repo, it looks like Apple does not ship libatomic at all, and there are a few tests disabled in the libcxx test suite because of it. But since LLVM and Binaryen already work just fine on mac (since they don't atomic ops on large non-lock-free types), we can probably just get away with disabling it.

[phlax]

it looks like the current build has the leaked shared libatomic.so.1

specifically we are hitting this with the wasm-opt bin - surely it should be compiled in

this breaks hermetic builds