<p dir="auto">Currently both deno itself and executable generated from <code class="notranslate">deno compile</code> are not static executable, but generating static executable will help a lot since some Linux distributes doesn't have glibc (like Alpine Linux, which is used widely in Docker).</p>
<p dir="auto">When trying to run deno on Centos 7, it fails:</p>
<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="[maxim@maxim deno] $ target/release/deno tests/worker.js
target/release/deno: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by target/release/deno)"><pre class="notranslate">[maxim@maxim deno] $ target/release/deno tests/worker.js
target/release/deno: /lib64/libc.so.6: version <span class="pl-s"><span class="pl-pds">`</span>GLIBC_2.18<span class="pl-s"><span class="pl-pds">'</span> not found (required by target/release/deno)</span></span></pre></div>
<p dir="auto">Additional information:<br>
First things first, Centos 7 is based on RHEL 7, as one may know. And, according to <a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/sect-red_hat_enterprise_linux-7.0_release_notes-compiler_and_tools-glibc" rel="nofollow">redhat.com</a>:</p>
<blockquote>
<p dir="auto">In Red Hat Enterprise Linux 7, the glibc libraries (libc, libm, libpthread, NSS plug-ins, and others) are based on the glibc 2.17 release</p>
</blockquote>
<p dir="auto">Replacing system glibc is a <a href="https://serverfault.com/questions/894625/safely-upgrade-glibc-on-centos-7#comment1155836_894689" rel="nofollow">very bad idea</a>, basically because all binaries on the system are compatible with specific glibc version. So, that's not an option.</p>
<p dir="auto">However, the RHEL 8 Beta is using glibc 2.28 (<a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html-single/8.0_beta_release_notes/index#compilers_and_development_tools_2" rel="nofollow">source</a>), but Centos 8 will only be released when the stable version of RHEL 8 will be released (<a href="https://www.centos.org/forums/viewtopic.php?t=68821" rel="nofollow">source</a>), so updating Centos is not an option right now.</p>
<p dir="auto">I have also tried installing glibc in a nonstandard location as described <a href="https://serverfault.com/a/894689/281189" rel="nofollow">here</a>. Unfortunately, when I try to run deno with that custom glibc, I'm getting:</p>
<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="[maxim@maxim deno]$ LD_LIBRARY_PATH=/opt/glibc-2.18/lib target/release/deno tests/worker.js
Segmentation fault (core dumped)"><pre class="notranslate">[maxim@maxim deno]$ LD_LIBRARY_PATH=/opt/glibc-2.18/lib target/release/deno tests/worker.js
Segmentation fault (core dumped)</pre></div>
<p dir="auto">I've tried to debug it with <code class="notranslate">lldb</code>, <code class="notranslate">gdb</code>, <code class="notranslate">abrt</code>, but neither option worked for me. Probably, because I'm doing something wrong.<br>
<code class="notranslate">lldb</code>:</p>
<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="[maxim@maxim deno]$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.18/lib lldb -- target/debug/deno tests/worker.js
lldb: relocation error: /opt/glibc-2.18/lib/libc.so.6: symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference"><pre class="notranslate">[maxim@maxim deno]$ LD_LIBRARY_PATH=<span class="pl-smi">$LD_LIBRARY_PATH</span>:/opt/glibc-2.18/lib lldb -- target/debug/deno tests/worker.js
lldb: relocation error: /opt/glibc-2.18/lib/libc.so.6: symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined <span class="pl-k">in</span> file ld-linux-x86-64.so.2 with link <span class="pl-k">time</span> reference</pre></div>
<p dir="auto"><code class="notranslate">gdb</code>:</p>
<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="[maxim@maxim deno]$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/glibc-2.18/lib gdb target/release/deno tests/worker.js
gdb: relocation error: /opt/glibc-2.18/lib/libc.so.6: symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference"><pre class="notranslate">[maxim@maxim deno]$ LD_LIBRARY_PATH=<span class="pl-smi">$LD_LIBRARY_PATH</span>:/opt/glibc-2.18/lib gdb target/release/deno tests/worker.js
gdb: relocation error: /opt/glibc-2.18/lib/libc.so.6: symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined <span class="pl-k">in</span> file ld-linux-x86-64.so.2 with link <span class="pl-k">time</span> reference</pre></div>
<p dir="auto">And <code class="notranslate">abrt</code> won't detect any crashes, even though I've set <code class="notranslate">OpenGPGCheck = no</code> and <code class="notranslate">ProcessUnpackaged = yes</code> in <code class="notranslate">/etc/abrt/abrt-action-save-package-data.conf</code>, restarted <code class="notranslate">abrtd</code> and <code class="notranslate">abrt-ccpp</code>, and finally tried rebooting, nothing helped.<br>
I hope, that I'm doing something wrong, because right now I think using custom glibc is the only option, if I don't want to containerize deno.</p>
<p dir="auto">Also, as far as I understand, GLIBC_2.18 isn't a direct requirement of deno, but rather a requirement of some third-party.<br>
I've found Chromium bug <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=749077" rel="nofollow">glibc dependency creeped up to 2.18 in M61, breaking EL7 support</a> which seems relevant, but it was fixed a while ago.<br>
I'm not really good in C or library symbols to find which dependency requires 2.18, so any help here would be really appreciated.</p>
<p dir="auto">I hope that <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/ry/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/ry">@ry</a> also would agree that we should support Centos, and probably when this issue got fixed, we can run travis not only for <a href="https://docs.travis-ci.com/user/reference/trusty/" rel="nofollow">Ubuntu 14.04 LTS (trusty)</a> but also for Centos. Many thanks for your attention!</p>