In general, we use a distributed network with many different versions of RH, so we can't rely on the standard installation locations. In addition, we tend to dynamically link or tools and manage them during compile. As such, many of our lib so files are in non-standard location. As such, that renders the usual download versions of prince unusable for us.

Is there a static version of prince 12.1? The documentation references this, and it may have been available for previous versions, but I do not see it available for 12.1 or the archived latest 11 versions.

Alternatively, where is prince looking for the shared object libs? I tried putting in a soft link in prince's lib dir (where libdatrie.so.1 and libthai.so.0 reside, but see no difference when calling prince)

Prince is just using the system shared object loader for most libraries, so you could modify the LD_LIBRARY_PATH environment variable if you have installed them in different locations.

the LD_LIBRARY_PATH is unfortunately not an option in our specific environment configuration...

What other options do we have?

The other way to configure the shared object loader is to edit /etc/ld.so.conf and then run ldconfig.

I'm not sure that will work either.

There is a potential for this "installation" of prince to run on different servers, and we'll never know if the server has been configured correctly to point to its local libs or the ones that we distribute with the package. Not able able to configure prince directly to point to a path of libs that we mirror makes it difficult for us, especially when our IT group also manages and adds new servers which may not also be configured. And if we start up virtual servers... well, it becomes a nightmare.

A static version is less ideal, but it would still work for our purposes as it remains self contained.

Another option is to try the Generic Linux package, which should be able to run on a wider range of versions.

I'm not sure what you mean by configuring Prince "directly", but the bin/prince file in the installation directory is a wrapper script that calls the executable, and should be a suitable place to set or modify the LD_LIBRARY_PATH variable in order to configure where RH's loader looks for shared libraries.

Well, package management has always been a sore spot in my company. For that reason, we always compile from source and include paths to our managed packages.

We have legacy computers, compilers, and systems that we support, so using built in package management doesn't work for us. Setting the LD_LIBRARY_PATH in the wrapper script allows me to resolve issues on the libs, it seems.

Thanks for your help, Mark and Mike! I'll respond back if I notice anything problematic with this solution.