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"

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

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

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

@dschuff

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?

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.

@shlomif

@shlomif what linux distro are you using?

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

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

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.

Update dependencies from https://github.com/dotnet/arcade build 20240…

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

bazel/sysroot: Add libatomic to workaround broken emscripten

bazel/sysroot: Add libatomic to workaround broken emscripten (#3415)

docker/debian: Add libatomic to workaround broken emscripten

docker/debian: Add libatomic to workaround broken emscripten (#513)

@dschuff

@dschuff do you know of any way to remove this dependency of to link it statically? I don't see any static version of libatomic my debian system (unless I'm missing something).

I can confirm that this is happening. Based on the logs it looks like the dependency might be coming from mimalloc. We last did a mimalloc update in June; what was the last version you were using that was good?

@sbc100

@sbc100 It looks like the sysroot we build in has libatomic.a though

@sbc100

[@sbc100 ](https://github.com/sbc100) It looks like the sysroot we build in has libatomic.a though

Strange.. do you know what package it comes from? Are you able to find that file on your system? (From what package?)

I think libatomic itself comes from gcc (https://github.com/gcc-mirror/gcc/tree/master/libatomic).
I have it on my system as /usr/lib/x86_64-linux-gnu/libatomic.so.1, as well as some version-specific .a files like /usr/lib/gcc/x86_64-linux-gnu/14/libatomic.a (and .so). Package-wise it looks like it's part of libgcc

Ah, ok, then there maybe some way to statically link libatomic.a then. Good news.

I didn't really want to mess with mimalloc's CMake files, but I found a way to keep mimalloc from using libatomic at all if it wasn't actually needed: WebAssembly/binaryen#8211

thanks or addressing this, really appreciated

Link mimalloc with --as-needed on Linux (WebAssembly#8211)

Navigation Menu

Repository navigation

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" #928

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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" #928

Description

Activity

shlomif commented on Nov 11, 2021

shlomif commented on Nov 11, 2021

sbc100 commented on Nov 11, 2021

dschuff commented on Nov 11, 2021

sbc100 commented on Nov 11, 2021

dschuff commented on Nov 11, 2021

sbc100 commented on Nov 11, 2021

dschuff commented on Nov 11, 2021

phlax commented on Jan 10, 2026

sbc100 commented on Jan 10, 2026

dschuff commented on Jan 15, 2026

dschuff commented on Jan 15, 2026

sbc100 commented on Jan 15, 2026

dschuff commented on Jan 15, 2026

sbc100 commented on Jan 15, 2026

dschuff commented on Jan 15, 2026

phlax commented on Jan 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions