I see this kind of tip suggested a lot when dealing with PASE issues:

export PATH=/my/path/bin:/other/path/bin:$PATH
export LIBPATH=/my/path/bin:/other/path/bin:$LIBPATH

That's not how this works! That's not how any of this works!

This misguided suggestion bugs me to no end, so today I'm here to educate and clear up confusion over LIBPATH.

We're on the Road PATH to Nowhere

Let's start by looking at the PATH. What is PATH?

PATH is an environment variable that is used by applications when they want to execute a program using an unqalified path to that application. For instance, you type in ls in your shell and hit enter. Because ls is not a qualified path, your shell1 has to qualify the path to ls and it does so using the colon-separated list of directories given on the PATH. You can think of PATH as equivalent to the library list used by MI programs.

So lets say your PATH looks like this:

/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:/usr/bin

When you execute ls, each of these dirctories will be searched in the order specified for an executable file named ls:

  • /QOpenSys/usr/bin
  • /usr/ccs/bin
  • /QOpenSys/usr/bin/X11
  • /usr/sbin
  • /usr/bin

Once it find a file at one of those paths, it will try to execute it. We can easily see where a program is found using the which command:

$ which ls
/QOpenSys/usr/bin/ls

This means that when you type lsat the command prompt, /QOpenSys/usr/bin/ls will be executed.

This colon-separated list of directories is a very powerful and useful tool and thus has been stolen appropriated by other utilities for their own use:

  • PYTHONPATH - list of directories to find Python modules
  • GEM_PATH - list of directories to find Ruby Gems
  • CLASSPATH - list of directories to find Java class files
  • LIBPATH - list of directories to find PASE/AIX shared libraries
  • ...

PATH != CLASSPATH != LIBPATH != ...

The thing to remember is that although these PATH-like variables look and act the same, their use is different. You would not normally expect Java .class files to exist in the same directory as Python .py files or Ruby .rb files or PASE binaries. This brings us back to LIBPATH: PASE shared libraries (.a and .so files) are normally stored in paths that end in lib/ or lib64/, not bin/ --- bin/ is where your programs live.

You should never set your LIBPATH and PATH to the same thing or add the same paths to both, unless you're doing something really odd, in which case I'd suggest you not do that and do something sensible instead. 😉

In the next entries, I'll talk about how AIX/PASE loading works, how LIBAPTH works, and why you should rarely need to set the LIBPATH at all anyway.

1 Really, the hard works is probably done by execvp ↩