Setting system-wide LIBPATH is always problematic. If any program requires LIBPATH to be set system-wide, then that program is not built properly. If it is supported, then you can open a case. 

Ayappan,

I brought it up to PowerHA development team as an issue to be addressed.

I'm not sure what you mean by "LIBPATH to be set system-wide". The program is currently linked against libxml2.a in /usr/ccs/lib/libxml2.a, BUT also uses libraries like libcurl.a and starting phyton from /opt/freeware/bin ...

There are plenty of programs requiring LIBPATH set to their application specific libraries via export LIBPATH=... (but no /usr/lib included!).  The issue here is that "/usr/lib" contains libraries, or symbolic links to libraries, which conflict with libraries in /opt/freeware/lib and, in addition, that libraries and programs in /opt/freeware/[lib|bin] do not try to load the required libraries FIRST from /opt/freeware/lib[64] before trying /usr/lib.

Nevertheless, there are plenty of similar issues with rpm, dnf,... reported where libraries (libsqlite and  libintl) in /usr/opt/rpm conflict with the versions in /opt/freeware/lib[64]. As it does not seem to be possible to keep the libraries included with rpm.rte and AIX Toolbox in sync, why can't the Toolbox binaries and libraries be configured/linked to search FIRST in the corresponding /opt/freeware/lib[64] ... directory where they originated before falling back to LIBPATH?

For example, if /opt/freeware/lib64/libpython3.7m.so would look for libintl.a in /opt/freeware/lib64 first, python3 would load successfully.

... I'm not a linker expert so do not know if the above is an option, but I'm wondering if that is the only option to get rid of this quite frequent issues reported as rpm.rte can not be removed from AIX.

Setting system-wide LIBPATH is always problematic. If any program requires LIBPATH to be set system-wide, then that program is not built properly. If it is supported, then you can open a case. 

All Toolbox packages have "/opt/freeware/lib" (for 32bit) or "/opt/freeware/lib64" (for 64bit) first in their library search path. So it's not a problem with AIX Toolbox packages. In this case, it's a problem with the PowerHA application. Remember,  application's library search path dominates the further loading libraries library search path. If application's first library search path is /usr/lib and if it links to libpython, then libpython will be linked against /usr/lib/libintl.a even though libpython's library search path has /opt/freeware/lib as the first. There is a way to change this by hardcoding /opt/freeware/lib/libintl.a inside the libpython's loader section. But this is not a trivial change and requires continuous maintenance. 

Ayappan,

I brought it up to PowerHA development team as an issue to be addressed.

I'm not sure what you mean by "LIBPATH to be set system-wide". The program is currently linked against libxml2.a in /usr/ccs/lib/libxml2.a, BUT also uses libraries like libcurl.a and starting phyton from /opt/freeware/bin ...

There are plenty of programs requiring LIBPATH set to their application specific libraries via export LIBPATH=... (but no /usr/lib included!).  The issue here is that "/usr/lib" contains libraries, or symbolic links to libraries, which conflict with libraries in /opt/freeware/lib and, in addition, that libraries and programs in /opt/freeware/[lib|bin] do not try to load the required libraries FIRST from /opt/freeware/lib[64] before trying /usr/lib.

Nevertheless, there are plenty of similar issues with rpm, dnf,... reported where libraries (libsqlite and  libintl) in /usr/opt/rpm conflict with the versions in /opt/freeware/lib[64]. As it does not seem to be possible to keep the libraries included with rpm.rte and AIX Toolbox in sync, why can't the Toolbox binaries and libraries be configured/linked to search FIRST in the corresponding /opt/freeware/lib[64] ... directory where they originated before falling back to LIBPATH?

For example, if /opt/freeware/lib64/libpython3.7m.so would look for libintl.a in /opt/freeware/lib64 first, python3 would load successfully.

... I'm not a linker expert so do not know if the above is an option, but I'm wondering if that is the only option to get rid of this quite frequent issues reported as rpm.rte can not be removed from AIX.

Setting system-wide LIBPATH is always problematic. If any program requires LIBPATH to be set system-wide, then that program is not built properly. If it is supported, then you can open a case. 

Ayappan,

thank you for the additional feedback. We worked with development and received an iFix which changed the library load options in the program and that resolved the linking issue as long as we do not need to set LIBPATH any longer.

I still believe that the library version conflict with the rpm.rte package for libsqlite and libintl should be investigated further and it should be evaluated if for those 2 conflicting libraries the path should be hard coded to force the /opt/freeware/lib versions first for any binaries/libraries from /opt/freeware/[bin | lib]. On AIX python/python2, is failing if you set LIBPATH=/usr/lib:/opt/freeware/lib and run /usr/bin/python or /usr/bin/python2, which are symbolic links to /opt/freeware/python2.

python
Could not load program python:
Symbol resolution failed for /opt/freeware/lib/libpython2.7.so because:
        Symbol _GLOBAL__AIXI_libsqlite3_so (number 219) is not exported from dependent
          module /usr/lib/libsqlite3.so.
        Symbol _GLOBAL__AIXD_libsqlite3_so (number 220) is not exported from dependent
          module /usr/lib/libsqlite3.so.
Examine .loader section symbols with the 'dump -Tv' command.

All Toolbox packages have "/opt/freeware/lib" (for 32bit) or "/opt/freeware/lib64" (for 64bit) first in their library search path. So it's not a problem with AIX Toolbox packages. In this case, it's a problem with the PowerHA application. Remember,  application's library search path dominates the further loading libraries library search path. If application's first library search path is /usr/lib and if it links to libpython, then libpython will be linked against /usr/lib/libintl.a even though libpython's library search path has /opt/freeware/lib as the first. There is a way to change this by hardcoding /opt/freeware/lib/libintl.a inside the libpython's loader section. But this is not a trivial change and requires continuous maintenance. 

Ayappan,

I brought it up to PowerHA development team as an issue to be addressed.

I'm not sure what you mean by "LIBPATH to be set system-wide". The program is currently linked against libxml2.a in /usr/ccs/lib/libxml2.a, BUT also uses libraries like libcurl.a and starting phyton from /opt/freeware/bin ...

There are plenty of programs requiring LIBPATH set to their application specific libraries via export LIBPATH=... (but no /usr/lib included!).  The issue here is that "/usr/lib" contains libraries, or symbolic links to libraries, which conflict with libraries in /opt/freeware/lib and, in addition, that libraries and programs in /opt/freeware/[lib|bin] do not try to load the required libraries FIRST from /opt/freeware/lib[64] before trying /usr/lib.

Nevertheless, there are plenty of similar issues with rpm, dnf,... reported where libraries (libsqlite and  libintl) in /usr/opt/rpm conflict with the versions in /opt/freeware/lib[64]. As it does not seem to be possible to keep the libraries included with rpm.rte and AIX Toolbox in sync, why can't the Toolbox binaries and libraries be configured/linked to search FIRST in the corresponding /opt/freeware/lib[64] ... directory where they originated before falling back to LIBPATH?

For example, if /opt/freeware/lib64/libpython3.7m.so would look for libintl.a in /opt/freeware/lib64 first, python3 would load successfully.

... I'm not a linker expert so do not know if the above is an option, but I'm wondering if that is the only option to get rid of this quite frequent issues reported as rpm.rte can not be removed from AIX.

Setting system-wide LIBPATH is always problematic. If any program requires LIBPATH to be set system-wide, then that program is not built properly. If it is supported, then you can open a case.