GCC links to library that does not exist - linux

Question

Will two libraries together produce a third library that does not even exist?
Try it here
Make sure there are icu and g++ on your machine
Output
ldd out1:
linux-vdso.so.1 (0x00007ffd5cdaf000)
liblcf.so.0 => /home/aleck099/.local/lib/liblcf.so.0 (0x00007ff200600000)
libicuuc.so.72 => /usr/lib/libicuuc.so.72 (0x00007ff200200000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff1ffe00000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007ff200518000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007ff2008a1000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007ff1ffc19000)
libicui18n.so.71 => not found
libicuuc.so.71 => not found
libicudata.so.71 => not found
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007ff200874000)
libicudata.so.72 => /usr/lib/libicudata.so.72 (0x00007ff1fde00000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff2008ea000)
ldd out2:
linux-vdso.so.1 (0x00007ffdfed78000)
libicui18n.so.72 => /usr/lib/libicui18n.so.72 (0x00007fa088000000)
libicuuc.so.72 => /usr/lib/libicuuc.so.72 (0x00007fa087c00000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa087800000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fa08834d000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa087fe0000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fa087619000)
libicudata.so.72 => /usr/lib/libicudata.so.72 (0x00007fa085800000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa08845e000)
You can see that three "not found"s in the ldd output of out1
They are even duplicates of existing icu libraries
How could this happen?
Other information
both clang and gcc produce the same result
liblcf.so is built from easyrpg

Answer 1

It looks like the link command used to create out1 picked up symbols from two different versions of the ICU library: libicuuc.so.71 and libicuuc.so.72. The 71 vs 72 is the version number. Those appear to be two different versions of the shared library that were both in the linker's library path. It's "not found" at ldd time because one copy is not in the runtime shared library search path, and even if it was mixing both is probably a bad idea.
The solution is likely to inspect your link command and ensure the -L options only include one version/copy of the ICU library.
EDIT: Linking with verbosity enabled (g++ -v option) will provide additional information about the libraries and paths being used.
Note that it's possible that some of the shared libraries pulled in by out1 are transitively pulling in the (non-existent) libicuuc.so.71. Comparing your two ldd executable outputs, I would be suspicious of /home/aleck099/.local/lib/liblcf.so.0 (and possibly /usr/lib/libexpat.so.1) that only appear in out1. The following command may help:
$ ldd /home/aleck099/.local/lib/liblcf.so.0 /usr/lib/libexpat.so.1