From: Jamulla, John D. (AMHERST) (jdj++at++amherst.com)
Date: 09/24/2002 06:31:45
Hello,
I'll try to make this problem description as simple and complete as
possible. I am running out of options of who to ask for help. I really
need one of the Performer team to examine what I wrote below and see if
they can help.
I have a C++ APP we are building with Performer 2.4.2 on IRIX 6.5.13m
and 7.3.1.3m compilers. I am trying to build it with the Performer
shared libs. I compiled this app with '-L /usr/lib32/Performer/Debug'
and '-L /usr/lib32/Performer/Debug/libpfdb' so it looks at the DEBUG
shared libs. I think this was a mistake (should have let it just look at
the /usr/lib32/ libs), but it should still work on a customer machine
with ONLY the runtime libs I thought. This is my first question, will
it? I know the answer is YES, because if I do something I can MAKE it
work (see below). It just doesn't work as I expect with the SGI
versioning scheme on the shared libs.
PROBLEM:
--------
If we "run" our app on a customer (or internal machine) without doing
anything to the LD_LIBRARYN32_PATH, it doesn't work. It appears it
cannot find the version of the libs it's looking for. I know they are
there and "ok". I've symlinked to them and get things to work (see
below).
Now a typical customer machine for us has 2.5 runtime Performer, 2.4.X
and 2.2.X runtime libs all loaded in /usr/lib32.
After reading the SGI docs on techpubs AT LENGTH, it appears that a
"mixing" of different versioned libs in one dir SHOULD work, because the
SGI versioning scheme should look for a libpf*.so, find it's the wrong
version, then build a NEW filename that's something like libpf*.so.5
(for performer 2.4.X) and re-do the path lookup as it always does.
Now, for us this isn't happening. Below is the error message, it appears
the versions search is "suppressed".
QUESTION: Why is this?
The way I can use these exact same libs and get the APP to run, is by
making my OWN directory somewhere, and putting in the libpf*.so.5 libs
(symlinked to /usr/lib32) and symlinking the libpf*.so libs to these
libpf*.so.5 libs. Then changing the LD_LIBRARYN32_PATH appropriately. It
does NOT work just having the libpf*.so.5 libs in there alone without
the symlinks to libpf*.so. I don't understand why, except there's
something this error message is telling me.
Here is the error message:
---------------------------
157385: 11:59:41
/net/iris41/home/tues/bin/n32/debug/SituationDisplay.normal: failed
version match /usr/lib32/libpfdu.so ver sgi4.0:sgi4.0.440:sgi4.1:sgi4.2
against req ver sgi5.0.250
157385:/net/iris41/home/tues/bin/n32/debug/SituationDisplay.normal: rld:
Warning: Version search suppressed in
/net/iris41/home/tues/bin/n32/debug/SituationDisplay.normal because
version (sgi5.0.250) of object libpfdu.so in liblist is not an sgi
interface version.
157385: 11:59:41
/net/iris41/home/tues/bin/n32/debug/SituationDisplay.normal: rld: Fatal
Error exit/longjmp: Cannot Successfully map soname 'libpfdu.so' version
'sgi5.0.250' under any of the filenames
/usr/local/MultiGen/mgapi/lib/libpfdu.so:/net/iris41/home/tues/dsolib/n3
2/debug/libpfdu.so:/net/iris41/home/tues/dsolib/n32/debug/multigen/libpf
du.so:/usr/lib32/libpfdu.so:/usr/lib32/internal/libpfdu.so:/lib32/libpfd
u.so:/opt/lib32/libpfdu.so:
157385:/net/iris41/home/tues/bin/n32/debug/SituationDisplay.normal: rld:
Fatal Error: Cannot Successfully map soname 'libpfdu.so' version
'sgi5.0.250' under any of the filenames
/usr/local/MultiGen/mgapi/lib/libpfdu.so:/net/iris41/home/tues/dsolib/n3
2/debug/libpfdu.so:/net/iris41/home/tues/dsolib/n32/debug/multigen/libpf
du.so:/usr/lib32/libpfdu.so:/usr/lib32/internal/libpfdu.so:/lib32/libpfd
u.so:/opt/lib32/libpfdu.so:
Here's the Elfdump -Dl of the APP:
-------------------------------------
/net/riss/riss01/dev_grp_011/bin/n32/debug/SituationDisplay:
**** MIPS LIBLIST INFORMATION ****
.liblist :
[INDEX] Timestamp Checksum Flags Name
Version
[1] Apr 18 12:01:47 2002 0x8f1d133c ----- libmgapilib.so
0
[2] Feb 1 16:01:46 2001 0x5fff06b7 ----- libmgdd.so
0
[3] Feb 1 16:01:46 2001 0x6baadca1 ----- libmgapistubs.so
0
[4] Feb 1 16:01:47 2001 0xc6818285 -----
libmgpluginmgr.so 0
[5] Feb 1 16:01:47 2001 0x6f0a1c5a ----- libmgruntime.so
0
[6] Feb 1 16:01:46 2001 0xd289844d ----- libmgdatamgr.so
0
[7] Feb 1 16:01:46 2001 0x1c8c4d49 -----
libmgessential.so 0
[8] Feb 1 16:01:47 2001 0xcf57e603 ----- libmgtxtmgr.so
0
[9] Feb 1 16:01:46 2001 0x461f4583 ----- libmgimgio.so
0
[10] Feb 1 16:01:47 2001 0x12e38382 ----- libmgtin.so
0
[11] Feb 1 16:01:46 2001 0x9d99ac3b ----- libmggeom.so
0
[12] Feb 1 16:01:47 2001 0x8d008bef ----- libmgtopology.so
0
[13] Jul 5 23:28:49 2001 0x6911e3f9 ----- libvk.so.1
sgi1.0
[14] Mar 5 13:28:51 2002 0x6f9cdc4d ----- libpfdu.so
sgi5.0.250
[15] Mar 5 13:28:52 2002 0xc44e7fcc ----- libpfui.so
sgi5.0.250
[16] Mar 5 13:28:53 2002 0xa1f8772a ----- libpfutil.so
sgi5.0.250
[17] Mar 5 13:29:46 2002 0x5278a12a ----- libpf.so
sgi5.0.250
[18] Mar 5 13:27:24 2002 0x7ee0122 ----- libfpe.so
sgi1.0
[19] Mar 5 13:27:24 2002 0xa74005b5 ----- libm.so sgi1.0
[20] Mar 5 13:28:40 2002 0xaebaff4e ----- libGLU.so
sgi1.0
[21] Mar 5 13:28:23 2002 0xfc78293c ----- libGL.so
sgi1.0
[22] Jan 23 18:18:10 2002 0x4e0ff19a ----- libXm.so.1
SGI LOOK -- Based on OSF/Motif 1.2.4#sgi1.0
[23] Jan 23 18:17:53 2002 0xcac7439d ----- libXt.so
sgi1.0
[24] Jan 23 18:18:51 2002 0x4b347566 ----- libXmu.so
sgi1.0
[25] Jan 23 18:17:28 2002 0x9ce4cd36 ----- libX11.so.1
sgi1.0
[26] Jan 23 18:18:11 2002 0x8626de0f ----- libXsgivc.so
sgi1.0
[27] Mar 5 13:27:22 2002 0x945af4c9 ----- libCsup.so
sgi1.0
[28] Mar 5 13:27:32 2002 0xa107d25b ----- libC.so.2
sgi2.0
[29] Jul 5 22:18:31 2001 0xeec4eea7 ----- libc.so.1
sgi1.0
I'm assuming this is why the "versioning" is not working as it's
documented, I found the versioning scheme described in at least 2 places
and it's not working as those say. I guess it's becuase of this error
message.
-------
Any help would be appreciated. The SGI support guys are not helpful at
all in this regard. They seem to not know what they are doing.
The best info they gave me so far is to re-load an inst package
'performer_dev.sw.hdr' from the 2.4.2 performer CDs (which makes no
sense to me). The problem is the versioning scheme isn't working
correctly.
Sincerely,
John J.
--- John D. Jamulla - Senior Engineer Northrop Grumman Corporation Electronic Systems Amherst Systems Buffalo N.Y. 14221, (716) 631-0088 jdj++at++amherst.com, or j.jamulla++at++ieee.org
This archive was generated by hypermail 2b29 : Tue Sep 24 2002 - 06:33:22 PDT