Could Not Load Library

The Genero runtime architecture makes use of shared libraries and a dynamic linker.  Prior to Genero 2.00 you may recall having to create a runner, since version 2.00 runner creation is no longer needed.

It varies by operating system, but there will be an environment variable that controls a list of paths used by the dynamic linker to search for the libraries.   LD_LIBRARY_PATH is the example I will use as being the most common, its documentation entry refers to the other values that maybe applicable for your operating system.

When you get a Could Not Load Library error message the first instinct should be to check the value of LD_LIBRARY_PATH and normally you find in the GAS or Genero Studio configuration that this value is not correct.  I used that case at the beginning of this article.

There are two other debug steps you should have in your toolbox ready to use if you have trouble resolving a Could Not Load Library error message.

The first is to recognise that when a library is loaded, any libraries that this library is dependent upon also need to be opened.  The error message could be pointing at the fact that it is one of these other libraries that could not be found.

In Unix/Linux world there is a command ldd (list dynamic dependencies)  that can be used to list the other libraries that will be loaded.  Other operating systems will have a similar command or technique that can normally be found by googling on “operating system equivalent of ldd” . (replacing operating system with the name of your operating system)

When the environment is not set correctly to find the dependencies, the ldd output will include a line like …

library file name => not found

… instead of the expected …

library file name =>/valid/path/to/library file name

When ldd indicates that  a dependency cannot be found, you either need to set LD_LIBRARY_PATH or its equivalent so that it will found the dependency, or sometimes it might be a case of needing to install the missing dependency.

The second trick in your toolbox is if you encounter the issue with something that is launched via RUN.  The Genero runner may add to LD_LIBRARY_PATH and hence the environment variable LD_LIBRARY_PATH may not be exactly what you think it is.  As a result a different version of a library is being found when you expect to find it further down the path.   This typically occurs with the libraries we ship in FGLDIR/lib being found by a non Genero executable.  A little test is to create a program to run from the command line …

#! dump_env.4gl
MAIN
    RUN "env | sort > env.2"
END MAIN

and then do

env | sort > env.1
fglrun dump_env.42m
diff env.1 env.2

You may find from this diff that LD_LIBRARY_PATH has an additional entry.  The solution here is to explicitly set LD_LIBRARY_PATH as part of the RUN to make sure the operating system finds the library you are expecting.

Final point is not to confuse LD_LIBRARY_PATH with FGLLDPATH.

FGLLDPATH is our invention and is used to find .42m files and c-extensions as needed by fglrun when it runs.

LD_LIBRARY_PATH and equivalents are the invention of the Operating System manufacturer and is used to find shared libraries needed by the operating system to execute fglrun.