1

Running ldd <dynamic_lib>, I noticed that there are some entries that read ??? => ???. Searching for a variety of combinations of "Linux", "ldd" and "??? => ???", both via search engine and on this site did not turn up anything.

Possibly relevant: the dynamic library in question was compiled on Windows 10 under MSYS2 using the built-in GCC Suite.

JDQ
  • 265
  • 2
  • 7
  • 1
    Possibly relevant: https://github.com/msys2/MINGW-packages/issues/4164 – muru Aug 13 '19 at 10:37
  • @muru I had resisted installing ntldd because I was working under the vanilla MSYS2 terminal, but I just downloaded it and it does seem very useful. Thanks! – JDQ Aug 13 '19 at 16:59

2 Answers2

0

The ldd command tries to link an executable or library to shared libraries in your system just as it happens when you run / use it. It will read library references from the given file and try to find them in your file system and path (LD_LIBRARY_PATH). If it displays "???" then this means that it cannot find some libraries in your system (and the program / library you have examined is likely not to run / be usable).

Often you will run into problems with libraries when you copy a file (executable or shared object library) from one system to another. The reason are differing system libraries - even if these only differ by version and otherwise exist.

Sometimes a solution is to copy missing libraries, too, and placing them in a folder that is included in LD_LIBRARY_PATH. You may also set that variable for this purpose, or append a new folder because you do not want to install those copied library files into your system (!).

You can find out which libraries to copy by running ldd on the original system.

If this is your own program or you have compiled it yourself you may in fact know which libraries are missing.

Once you have identified your libraries, you could copy them in a personal folder, e.g. into ~/libs. Then add this folder into your library path:

export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}":~/libs

if the variable already exists (test by echo $LD_LIBRARY_PATH), or 

export LD_LIBRARY_PATH=~/libs

if it does not (both bash-style shell syntax).

Then, try ldd again.

Later, you could start your actual program always using a shell script that sets the variable, then starts your program.

Ned64
  • 8,486
  • 9
  • 48
  • 86
  • In my case, I have compiled the library myself and I am attempting to load it on the same system. It is likely that my issue is indeed that the paths to the missing libraries are not included on LD_LIBRARY_PATH. – JDQ Aug 13 '19 at 17:02
  • @JDQ OK, added something to the answer, please test and let me know. – Ned64 Aug 13 '19 at 17:08
  • Although the issue I was having turned out to be specific to the way that Windows deals with shared libraries, I am going to select your answer as it addresses the original, overall question. Thanks! – JDQ Aug 15 '19 at 18:06
0

For those running into the same issue on Windows under MSYS2 (using the GCC Suite to compile a shared library, linking an executable to that library, and then finding that dependencies are missing at runtime) you can,

  1. copy the shared library to the same directory as the executable.
  2. link to the shared library from the same directory as the executable.
  3. modify the path environment variable to include the directory that contains the shared library.

MSYS2 may provide a Unix-like environment on Windows, but we still need to adhere to the way in which Windows searches for executables (including shared libraries) at runtime (in short, LD_LIBRARY_PATH is meaningless and the linker does not care about paths supplied with rpath; PATH should be used).

JDQ
  • 265
  • 2
  • 7