Status: Verified
SYMPTOM(s):
Errors appear running code that creates XML object
The proxml.dll or libproxml.so was missing or incomplete or XML could not be initialized. (9088)
Could not open Dynamic Library: <libraryName> (8013)
Could not open Dynamic Library: $DLC/lib/libproxml.so (8013)
Could not open Dynamic Library: $DLC/lib/libproxml.a (8013)
Could not open Dynamic Library: $DLC/lib/libproxml.sl (8013)
DLL Error : <dllerror> (8014)
DLL Error : No such file or directory (8014)
DLL Error : Could not load module. (8014)
The proxml.dll or libproxml.a was missing or incomplete or XML could not be initialized. (9088)
The proxml.dll or libproxml.sl was missing or incomplete or XML could not be initialized. (9088)
Cannot create widget of type <type>. (3181)
Cannot create widget of type X-DOCUMENT. (3181)
Cannot create widget of type X-SAXREADER. (3181)
FACT(s) (Environment):
Environment variables have been properly set.
The user account running _progres is different than the owner of the _progres executable.
UNIX
Progress 9.1E
OpenEdge 10.x
CAUSE:
Additional libraries (Xerces, ICU) required by Progress cannot be found automatically by the system in $DLC/lib.
This issue arises because the certain variables (LIBPATH variable for AIX; SHLIB_PATH variable for HP-UX; or LD_LIBRARY_PATH variable for most other operating systems) which are used to tell the operating system where to find additional libraries are not being set or are not being used.
This can happen when the user account running _progres is different than the owner of the _progres executable: in this case, the handling of the variable may be disabled by the operating system for security reasons, and the system is then unable to find missing shared library dependencies since they are not present in the standard directories.
This can also occur if a custom script is being run to start Progress and the variables which are normally set by the proenv; slib_env; java_env; slibod_env or sql_env scripts are not set in the custom script.
FIX:
First test to see under the user account which received the above errors if SHLIB_PATH; LD_LIBRARY_PATH or LIBPATH are set for the respective operating systems.
If those variables are set to at least contain $DLC/lib then proceed to the following steps.
Depending on the environment, three solutions are available:
Please note. The extentions to the libraries varies depending on the UNIX platform.
.so - Linux 32-bit and 64-bit
.so - SCO
.so - SUN 32-bit and 64-bit
.so - TRU64
.so - AIX 32-bit
.a (and .so) AIX 64-bit
.sl - HP 32-bit and 64-bit
in otherwords, the .so (and .sl in the case of HP) are dynamically built
the .a is statically built libraries in the case of AIX (64)
which means that when libraries are needed to be copied / linked / built
if present, it is always the .so on 32-bit, .a on 64-bit in this particular XML case for AIX.
SOLUTION#1:
If there is only one version of Progress / OpenEdge installed, the missing libraries should be made available in one of the standard system directories for shared libraries. This can be done by either:
1a) copying $DLC/lib/*psc.a or $DLC/lib/*psc.so or $DLC/lib/*psc.sl to /usr/lib
ie., the following files will be copied to the /usr/lib
-rwxr-xr-x 1 root system ... /usr/lib/libicudata-psc.[a | so | sl]
-rwxr-xr-x 1 root system ... /usr/lib/libicui18n-psc.[a | so | sl]
-rwxr-xr-x 1 root system ... /usr/lib/libicuuc-psc.[a | so | sl]
-rwxr-xr-x 1 root system ... /usr/lib/libxerces-psc.[a | so | sl]
OR
1b) creating symbolic links from $DLC/lib/*psc.a or $DLC/lib/*psc.so or $DLC/lib/*psc.sl to /usr/lib,
ie., ln -s [DLC]/lib/*psc.so /usr/lib
(On AIX servers, run "./slibclean" to reinitialize the shared library cache afterwards)
SOLUTION#2:
If there are multiple versions of Progress / OpenEdge installed for the same architecture (either all 32bit or all 64bit), apply the same solution as above, using the more recent version of Progress / OpenEdge to copy the files. They should be backwards compatible with older versions as well.
SOLUTION#3:
If there are multiple versions of Progress / OpenEdge installed for different architectures (mix of 32bit and 64bit versions), then this solution cannot be used. Instead, one must write a wrapper in C around the Progress binaries that provide the following features:
1. runs as setuid
2. sets LIBPATH upon execution to $DLC/lib
3. runs the final Progres executable (either _progres or _proapsv)