Hi Rich,
well, this is a long post. I think I can answer some of the questions:
> Where is the proper place to install/find these libraries on SAP systems?
Originally, these libraries were meant for usage by external programs, so they were not shipped/installed with the SAP System. Users who needed them for their programs would have to download and install them. The place, where they are installed, does not matter, because in my opinion adding the lib directory of the SDK to the LD_LIBRARY_PATH should be part of that "installation process".
However, starting with SAP Kernel 7.40, the NW RFC libraries have now been added to the kernel, so they can indeed be found in the DIR_EXECUTABLE directory of the SAP system. Please note: note 1739797 is not about the NW RFC SDK or the SAP Kernel, it is about the Internet Graphics Server (IGS), which already required the NW RFC libs before Release 7.40, so made this "special solution" for IGS running on SAP Systems < 7.40.
I think this also answers the next two questions. Basically the simplest solution for you would be:
- If running on a SAP system with Kernel 7.40 or higher, the libraries are already there and can be found in DIR_EXECUTABLE. (Note that the current "backward compatible kernel" used by all SAP systems of Release 7.4x is 7.42. So if the customer has not fallen too far behind with applying the regular kernel patch levels, you can expect the libraries to be there on all systems > 7.20.)
- If running on an older SAP system (4.6D, 6.20, 6.40, 7.00, 7.20 - I don't expect any older systems to be still in use these days) or on a standalone server, your customer would have to download and extract the SDK as described in note 1025361, and add the lib subdirectory to the LD_LIBRARY_PATH. I think, if you document this clearly in the installation instructions of your product, it should not be too much of a problem andf you can take it for granted?!
One special comment regarding libicudecnumber: if your program does not process function modules that have parameters of type DECFLOAT, then you don't need this library. It is independent of the other libraries, so you also don't need to link it at all. (A bit of background: there are two DECFLOAT types, a 16bit and a 34bit version, originally introduced by IBM DB2. In one of the recent SAP Kernel releases it was also added as a new ABAP data type. As of today, only a very small number of applications use this type, and fewer still use it in an RFC interface. So most probably you won't need it.)
(PS: libicudecnumber.so is not shipped with the kernel. Aparrently none of the helper executable needs it, and the kernel has linked it statically. So if you do need to process DECNUMBER values, you will depend on the NW RFC SDK being installed separately on any host.)
> Are there linker options for "lazy" runtime binding?
I would expect that this is highly platform-dependent... In any case, the NW RFC lib doesn't have any special support for it (even if it would be possible on all platforms that we support).
> Unfortunately, our binary is setuid and that disables options like RPATH or environment
> variables like LD_LIBRARY_PATH for security reasons.
Now this is indeed a difficult problem. I don't know an easy solution either, but to be honest: the dlopen() approach is ugly and cumbersome, isn't it? Anything would be better than this! But even setuid processes are allowed to load libraries from the standard directories like /usr/lib, so one option would be to copy the NW RFC libs there (or create symlinks).
And I found the following very interesting & instructive article, which documents two methods that should work on Linux (not sure about the various Unixes, though):
- Include the NW RFC lib directory in the file /etc/ld.so.conf. Then even setuid processes will find and load them!
- Alternatively: when starting the process, make sure that the uid and effective uid (as well as gid and effective gid) are equal. (So basically root needs to become the file owner of your binary.) Then LD_LIBRARY_PATH will be used for loading shared libs, even if the process runs as root!
See the following article for the details: Library Linking and setuid executables - Kevin R Tower - UW Information Technology Wiki
Hope I was able to help a bit.
Best regards, Ulrich
Message was edited by: Ulrich Schmidt - Correction about backward compatible kernel. - libicudecnemuber not distributed with the kernel.