Skip to main content

​
uWSGI error: cannot open shared object file libpcre.so.1

​
Error

uwsgi: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory

​
Cause

This error occurs in model builds when uWSGI can’t find one of its dynamically linked libraries. The model builds successfully, but fails to start. Instance logs show the uWSGI error.

​
Solution

Use the ldd (list dynamic dependencies) command to identify the missing library and its expected location, then create a symlink or update the library path to resolve it.

​
Step 1: Reproduce the error in a workspace

$ uwsgi uwsgi: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory

​
Step 2: Locate the uWSGI binary

$ which uwsgi /usr/local/anaconda/bin/uwsgi

​
Step 3: Identify the missing library

Run ldd against the uWSGI binary to see all dynamically linked libraries: $ ldd /usr/local/anaconda/bin/uwsgi linux-vdso.so.1 (0x00007ffe9d5ec000) libpthread.so.0 (0x00007f95e83ad000) libm.so.6 (0x00007f95e800f000) libdl.so.2 (0x00007f95e7e0b000) libz.so.1 (0x00007f95e7bee000) libpcre.so.1 => not found libuuid.so.1 (0x00007f95e79e7000) libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f95e777d000) libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f95e7305000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f95e6f44000) libutil.so.1 (0x00007f95e6d41000) libcrypt.so.1 (0x00007f95e6b09000) libc.so.6 (0x00007f95e6718000) /lib64/ld-linux-x86-64.so.2 (0x00007f95e85cc000) libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f95e6361000) liblzma.so.5 (0x00007f95e613b000) libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f95e4592000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f95e4209000) libgcc_s.so.1 (0x00007f95e3ff1000) Two things to note in this output:
  • libpcre.so.1 shows not found
  • Most resolved libraries point to /usr/lib/x86_64-linux-gnu/, which is where uWSGI searches for its dependencies
Confirm the search path by checking the LD_LIBRARY_PATH environment variable: $ echo $LD_LIBRARY_PATH /usr/lib/x86_64-linux-gnu/:/usr/local/cuda/lib64:/usr/local/nvidia/lib:/usr/local/nvidia/lib64:/opt/oracle/instantclient_12_1:/usr/local/cuda/lib64:/usr/local/nvidia/lib:/usr/local/nvidia/lib64:/opt/oracle/instantclient_12_1:

​
Step 4: Resolve the missing library

Choose one of the following options:
  1. Create a symlink from an existing versioned library in /usr/lib/x86_64-linux-gnu/. If libpcre.so.3 exists there, run: ln -s /usr/lib/x86_64-linux-gnu/libpcre.so.3 /usr/lib/x86_64-linux-gnu/libpcre.so.1
  2. Create a symlink from a library found elsewhere on the system. Use find to locate available copies: $ find / -name libpcre.so.1 /usr/local/anaconda/pkgs/pcre-8.43-he6710b0_0/lib/libpcre.so.1 /usr/local/anaconda/pkgs/pcre-8.44-he6710b0_0/lib/libpcre.so.1 /usr/local/anaconda/lib/libpcre.so.1 /libpcre.so Then link one of those paths into the expected directory: ln -s /usr/local/anaconda/lib/libpcre.so.1 /usr/lib/x86_64-linux-gnu/libpcre.so.1
  3. Update LD_LIBRARY_PATH to include the directory containing libpcre.so.1: export LD_LIBRARY_PATH=/usr/local/anaconda/lib/:$LD_LIBRARY_PATH

​
Step 5: Verify the fix

  1. Re-run ldd and confirm libpcre.so.1 now resolves to a path instead of showing not found: $ ldd /usr/local/anaconda/bin/uwsgi linux-vdso.so.1 (0x00007ffffc181000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f30d6d35000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f30d6997000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f30d6793000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f30d6576000) libpcre.so.1 => /lib/x86_64-linux-gnu/libpcre.so.1 (0x00007f30d6304000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f30d60fd000) libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f30d5e93000) libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f30d5a1b000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f30d565a000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f30d5457000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f30d521f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f30d4e2e000) /lib64/ld-linux-x86-64.so.2 (0x00007f30d6f54000) libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f30d4a77000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f30d4851000) libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f30d2ca8000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f30d291f000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f30d2707000) libpcre.so.1 now resolves to /lib/x86_64-linux-gnu/libpcre.so.1.
  2. Start uWSGI and confirm it runs without the shared library error: $ uwsgi Starting uWSGI 2.0.19.1 (64bit) on [Fri Oct 9 22:49:20 2020] *** compiled with version: 4.8.5 on 09 October 2020 19:29:50 os: Linux-4.4.0-1075-aws #85-Ubuntu SMP Thu Jan 17 17:15:12 UTC 2019 nodename: domino-run-5f80e2df4cedfd0008f5d7d4 machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 4 current working directory: /lib/x86_64-linux-gnu detected binary path: /usr/local/anaconda/bin/uwsgi WARNING: you are running uWSGI without its master process manager *** your memory page size is 4096 bytes detected max file descriptor number: 4096 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) The s/-socket option is missing and stdin is not a socket. uWSGI starts successfully without the shared library error.
If this solution doesn’t resolve your issue, please contact Domino Support.
Last modified on October 12, 2026