William Sherman -Visualization (wsherman++at++ncsa.uiuc.edu)
Thu, 16 Apr 1998 04:13:27 -0500 (CDT)
[Okay, after my recent posting of the "easy" question -- which
I figured would be easy because I expected the answer to be "No,
can't be done" -- I'm now sending my "hard" question with lots
of information. Perhaps it's too much, but seems to be a serious
problem with trying to operate in an environment with applications
compiled with different versions of Performer, and I would guess
that there are others in the same predicament.]
After a couple of recent upgrades on one of our Onyxes, I have a
question regarding the way to get older Performer applications
to continue to run: What is the way to get older Performer
applications to continue to run?
Here are some details:
Our Onyx's overall system was upgraded to a special R10K version
of IRIX 6.2 in February. Things seemed so be okay following that.
Not long afterward, Performer 2.2 was installed (prior to this
installation, it had Performer 2.1, with comptatibility modules
for 1.2 and 2.0 apps). I'm pretty sure all the apps we were
running were some flabor of 2.0 or 2.1 (is there a string that
is embedded in the executable that would give specific information?).
After 2.2 was installed, many applications simply failed to work,
or work properly (ie. some just crashed, others came up, but with
all the objects missing, or severely deformed). The deformed objects
were mostly (if not entirely) Inventor objects.
I've heard that there is a missing loader for Inventor objects
under 2.2, but since these are pre-2.2 apps, I don't understand
why they would begin to fail. But that does seem to be related
to the problem. Many of the following errors are reported for
one particular application:
! PF Warning/Usage: pfAddChild: Bad child 0x0.
! PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "iv20"
! PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "iv"
! PF Warning: pfdLoadFile() - Unable to load file sun.wrl because of problem finding pfdLoadFile_wrl
Looking at the installed products, I found:
! I performer_eoe.compatO32.performer1_2 02/12/98 Performer1.2 Compatibility DSOs (o32)
! I performer_eoe.compatO32.performer2_0 02/12/98 Performer2.0.5 [2.0-2.0.4] Compatibility DSOs (o32)
! I performer_eoe.compatO32.performer2_1 02/12/98 Performer2.1.3 [2.1-2.1.2] Compatibility DSOs (o32)
among others. Though I did notice that there are compat.sw{32,64},
listings for performer2_0_1, but not 2.1.
Probably the most interesting thing is what we found in /usr/lib.
For all the performer so libraries, there are multiple versions
ending in .2 .3 and .4. Presumably the ".4" files are for Performer
2.2 (there are no ".4" libraries on our other Oynx that does not
have 2.2 installed). However, examing the usage dates (ls -lu) in
/usr/lib/libpfdb indicates that running per 2.2 applications accesses
the ".4" files, and not the others. Further, the access comes via
softlinks that point to a file that ends in just ".so" and links
to the ".so.4" version.
So apparently, all our performer applications are using whatever
are the generic default shared libraries on a given machine,
regardless of which version they were compiled with. I was under
the impression that the backward compatibility products would
handle this appropriately.
Anyway, as a partial solution, we made some new subdirectories
in /usr/lib containing a list of all the shared object libraries,
and linking to either ".2", ".3" or ".4" files -- ie. one directory
links to all the ".2" files, etc. Then by setting the LD_LIBRARY_PATH
environment variable to one of these directorys and running the
applications, they now work -- almost. The objects are all of the
correct shape, and texture maps seem to work properly (except for
transparency), but objects that are colored by other means (ie.
material specifications) just show up as grey.
>From another recent message to info-performer, I gather there is
a compile flag that allows one to specify specifically which
shared objects will be used at run-time. However, while this
may help for a couple of cases, we also run applications sent
to us by other parties, and which we cannot compile locally.
... [time passes]
After some more research, we find that the dsos for the same library
are actually different on each of the two machines.
Looking at just the main libpf_ogl library on each of two machines, where
the one running 2.1 works, and the one with 2.2 has problems running older
applicaitons:
machine_at_2.1% showfiles | grep usr/lib/libpf_ogl.so
l 0 0 patchSG0001696.performer_eoe_sw.ogl_performer usr/lib/libpf_ogl.so
l 0 0 performer_eoe.sw.ogl_performer usr/lib/libpf_ogl.so
f 5701 3936408 patchSG0001696.performer_eoe_sw.ogl_performer usr/lib/libpf_ogl.so.2
f 63401 3931792 performer_compat.sw.performer2_0_1 usr/lib/libpf_ogl.so.2
f 28704 4536640 performer_eoe.sw.ogl_performer usr/lib/libpf_ogl.so.3
[where usr/lib/libpf_ogl.so links to usr/lib/libpf_ogl.so.3]
and:
machine_at_2.2% showfiles | grep usr/lib/libpf_ogl.so
l 0 0 performer_eoe.swO32.ogl_performer usr/lib/libpf_ogl.so
f 52895 3931792 performer_compat.sw.performer2_0_1 usr/lib/libpf_ogl.so.2
f 28670 3941708 performer_eoe.compatO32.performer2_0 usr/lib/libpf_ogl.so.2
f 49284 4550080 performer_eoe.compatO32.performer2_1 usr/lib/libpf_ogl.so.3
f 59247 6661200 performer_eoe.swO32.ogl_performer usr/lib/libpf_ogl.so.4
[where usr/lib/libpf_ogl.so links to usr/lib/libpf_ogl.so.4]
In these two cases, both machines are Onyx1s with R10K cpus and two IRs.
Also, I guess I haven't quite figured out the syntax for LD_LIBRARY_PATH,
because when I do something like:
% setenv LD_LIBRARY_PATH /usr/lib/libpf_ogl3_pic:/usr/lib/libpfdbso3
before running my app, and then do an "ls -u on these directories and
on /usr/lib, it indicates that the libraries in /usr/lib were accessed
instead -- with the resultant incorrect rendering (grey objects and no
transparency).
And just to state it explicitly, yes some of the problems go away when
the applications are recompiled in 2.2, but that's not an acceptable
solution. For one thing, we don't have the source to all the apps
we run, and for another thing, we've only upgraded one machine to
2.2 thus far, and except for evaluating 2.2, most of the time, apps
will be compiled on 2.1 or earlier so they can run on a range of
machines.
Please help.
Thanks,
Bill
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:15 PDT