Since I’ve installed ADABAS 5 on my HP-UX 11.23 (11i Rel.2) PA-RISC 64-bit server, I’ve been seeing this message all over the place:
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol ‘SMP_V213’ in load module ‘/sag/ada/v51103/lib/libadacom.sl’.
The last portion varies based on what utility I’m using: …/bin/adainv.bin, …/bin/adanuc.bin, …/bin/adabck.bin, …/bin/adaopr.bin, etc. But not consistantly.
I’ve check the version of the /sag/common/lib/libsagsm2.sl, which is 2.13.1, and adawrp is adding the $ADADIR/$ADAVERS/lib to the SHLIB_PATH environment variable. I’m not sure what else to check, but something must not be correct or define correctly.
Of course, after I post my previous message, I need to add that I am also running ENTIRE NET-WORK v722 and the SAG Directory Server which both have their own version of libsagsmp2.sl, which is v2.9.1.
Could these two versions of libsagsmp2.sl be in conflict? Should I replace the older versions of libsagsmp2.sl in the WCP and ADI directories? What affect will this have on these products?
Again, any assistance would be greatly appreciated.
Did you try running this based on a sagenv script without WCP and ADI, do the messages go away ?
This way you’d be sure if one of these is getting in the way.
Additionally you might want to check if LD_LIBRARY_PATH or LD_LIBRARY_PATH64 interfere with SHLIB_PATH
LD_LIBRARY_PATH64 is not really used any more and is not presently set. LD_LIBRARY_PATH is used only by ENTIRE ACCESS and is set to ‘/sag/osx/v5311/bin’ and nothing more.
I have not tried removing the ADI and WCP environment settings from the /sag/sagenv file. Their version of libsagsmp2.sl is definately not in the path before the ADABAS version, so the newer version of libsagsmp2.sl should be found first.
However WCP and ADI are currently active on this server. I was wondering if there could be a problem with ADABAS using its own version of libsagsmp2.sl if the WCP or ADI version is currently active?
In order to do a proper test, besides removing the WCP and ADI environment settings, I would also want to shut them down.
Just copy sagenv.new (or whatever you are using instead) to something else and just keep sagbaseenv and adaenv, then logout, login again, execute the newly created script (which only works when you don’t call sagenv from .profile, of course), just to make sure no other envvars are set.
Then start adaopr and see if the messages are gone.
This won’t affect ADI or WCP, you won’t have to shut it down either.
I left WCP and ADI running and just commented them out from the sagenv. This seems to have resolved the problem.
I don’t think it’s the SHLIB_PATH or the LD_LIBRARY_PATH. I think it’s PATH. Both ADI and WCP add their own directories to the PATH where the older version of libsagsmp2.sl can be found.
Do ADI and WCP support the newer version of the libsagsmp2.sl?
The order of the sagenv is the base tech, ADI, ADA and then WCP. I don’t think the order in the sagenv matters because ADA inserts itself at the beginning of the PATH, where ADI and WCP append themselves to the end of the PATH.
The problem is that ADABAS only inserts $ADADIR/$ADAVERS and $ADADIR/$ADAVERS/tools to the beginning of the PATH. It doesn’t insert $ADADIR/$ADAVERS/lib where the new version of libsagsmp2.sl is found.
The same holds true for the base technology. It inserts its bin directories to the beginning of the PATH, but not its library directory where the new version of libsagsmp2.sl (installed by ADABAS 5) is found.
Seems strange that ADABAS is searching the PATH for a shared library before it searches SHLIB_PATH, but that’s what it appears to be doing.
I can manually add $ADADIR/$ADAVERS/lib to the PATH, but until we know what affect the new version of the libsagsmp2.sl will have on ADI and WCP, I rather not chance it. Can you find out if the new version of libsagsmp2.sl is compatible with ADI and WCP?
ADABAS v5.1 does provide some changes in LD_LIBRARY_PATH handling with ADABAS utlities under Unix.
All ADABAS utility relevant libraries are wrapped via wrapper script. Please never use .bin (like adanuc.bin) executables directly. If your installation was succeed, a link have to be set from
$ADADIR/$ADAVERS/adanuc to $ADADIR/$ADAVERS/bin/adawrp
adawrp is a wrapper script, which set LD_LIBRARY_PATH correctly.
You must use $ADADIR/$ADAVERS/adanuc to start ADABAS or respectivly use
other ADABAS utility. adanuc.bin is definitly incorrect. The wrapper script should provide
LD_LIBRARY_PATH information for you.
When this link is not set correctly after installation, please contact ADABAS support
to analyze this faulty.
That sounds good in theory, but doesn’t work in reality. the unresolved symbol ha nothing to do with the ADABAS Wrapper, but with the difference is versions of libsagsmp2.sl shared by ADABAS, ENTIRE NET-WORK (WCP) and the SAG Directory Server (ADI).
While the ADABAS Wrapper may insert the $ADADIR/$ADAVERS/lib at the beginning of the LD_LIBRRAY_PATH, it does nothing for the fact that the older version of libsagsmp2.sl used by WCP and ADI have been previously defined to the PATH. Unlike ADABAS, ADI and WCP don’t have separate sub-directories for shared libraries and binaries. Both are stored together and both are placed in the PATH. And the mechanism loading a shared library searches the PATH before searching the LD_LIBRARY_PATH.
To corrected this problem it was recommended to me by development, to replace the libsagsmp2.sl files in the ADI and WCP subdirectories with the newer version provided by ADABAS. This way, the correct version of the libsagsmp2.sl would found, regardless of the wrapper, or the PATH or the LD_LIBRARY_PATH. So much for the the wrapper.
The ADABAS wrapper is an interesting concept, but doesn’t really work as long as it operates in a vacuum without consideration of other SAG products that may be installed and operational. Working in a vacuum without regards to other SAG products seems to be the reality that all the product development groups seem to be working in these days. I can say this having spent that last 3 months with SAG personnel on-site, the Support Center and Development all trying to get ADABAS, ENTIRE X Communicator, ENTIRE NET-WORK, NATURAL and the Base Technology all working together on a single server. All I can say is that it has been a nightmare.
Dynamic libraries are searched in LD_LIBRARY_PATH and then in SHLIB_PATH
on HP-UX systems. On 32Bit HP-UX only SHLIB_PATH is used.
PATH is never used to search for dynamic libraries on Unix systems.
On Windows Systems PATH is used to load dlls.
The wrapper script works well on all HP-UX systems here. Even with ADABAS
and ADI installed on same $SAG environment.
Can you please specify your configuration why PATH or LD_LIBRARY_PATH
is not set correctly to the right location. There must be anything wrong, because in normal case the wrapper script works and/or $SAG/common/lib is fallback path to search for libraries and here the newest version should be stored with any
Software AG installation.
after some rethinking and testing with adawrp I found the problem your and
perhaps other environment have.
ADABAS adawrp wrapper does only set SHLIB_PATH. But HP-UX does look in
LD_LIBRARY_PATH first and then in SHLIB_PATH. If you have set LD_LIBRARY_PATH to an path having libsagsmp2.sl, this library was taken
first.
You can add a line to adawrp and then it would run with wrapper:
HP-UX)
LD_LIBRARY_PATH=“$ADALIB${LD_LIBRARY_PATH:+”:“}${LD_LIBRARY_PATH:-}”
SHLIB_PATH=“$ADALIB${SHLIB_PATH:+”:“}${SHLIB_PATH:-}”
export SHLIB_PATH
;;
Other than we are HP-UX 11.23 64-bit PA-RISC, I’m not sure what I can tell you, but even with the wrapper the wrong version of the libsagsmp2.sl was found. Neither ADI nor WCP add themselves to either LD_LIBRARY_PATH or SHLIB_PATH, but only to PATH.
If there is a way to configure how shared libraries are searched for I don’t know how. Given the error messages I would receive like this one below, I can see that the ADABAS 5 library is being searched.
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol ‘SMP_V213’ in load module ‘/sag/ada/v51103/lib/libadacom.sl’.
However, if the ‘/sag/ada/v51103/lib/libsagsmp2.sl’ had been loaded, then the ‘SMP_V213’ code symbol would have been resolved. By the error messages, it obviously was not.
I checked both the ‘/sag/ada/v51103/lib/libadasmp2.sl’ and the ‘/sag/common/lib/libsagsmp2.sl’ and both were the correct version which includes the ‘SMP_V213’ code symbol.
There were only two other copies of the ‘libsagsmp2.sl’ installed on the server. They were both older versions that did not include the code symbol ‘SMP_V213’ and were located in ‘/sag/adi/libsagsmp2.sl’ and ‘/sag/wcp/v722/libsagsmp2.sl’. Neither defined to LD_LIBRARY_PATH nor SHLIB_PATH. Both defined to PATH. And both products are currently active.
My initial thoughts were that because these products were currently active and their version of the ‘libsagsmp2.sl’ already loaded that the ADABAS 5 version wasn’t reloaded when called, but development rejected this idea. If I shutdown both ADI and WCP the errors continued with ADABAS. If I removed both ADI and WCP from the path, the errors went away. If I put either ADI or WCP back into the PATH the errors returned. Clearly this is an environmental issue and PATH is being searched before LD_LIBRARY_PATH and SHLIB_PATH. I don’t know how to change the search order for shared libraries and developments only advice was to replace the ‘libsagsmp2.sl’ in ADI and WCP with the ADABAS 5 version.
One I did this, all the errors went away. End of story.
If this is an HP-UX configuration issue (to search the PATH for shared libraries or not) please let me know and I’ll pass it along to development. However, the fact that ADI and WCP as with other SAG products have their own shared libraries that are not placed in the LD_LIBRARY_PATH and SHLIB_PATH I don’t see that I have a choice but to continue searching the PATH for shared libraries. Maybe the search order can be changed?
You recommendation to change the ADABAS Wrapper is probably a good idea. I think this change needs to go to SAG development for the next PL of ADABAS. Maybe even as an Early Warning.
But before I start making any changes… are you a really smart SAG customer or a SAG employee?
Either way, now that I’m more or less past this issue, I definately have some other issues I would like to run past you.
