Sharon Clay (src++at++rose.engr.sgi.com)
Thu, 16 Apr 1998 03:02:49 -0700
Bill,
The short of if is that I think there is probably a simple explanation
to the behavior that you are seeing and hopefully a little info on
how DSOs work will help you clear it up. Otherwise, you should call
the TAC for help.
Executables will use the version of performer libs that they are
marked with for that lib.
% elfdump -L on an executable shows you the libraries by that program
and their needed version numbers.
Unless compiled with special flags, only the major part of the number
matters. This major number is what is appended to the library name.
At runtime, rld will look for libname.so.# where # is that major number.
The default libname.so links _only_ matter for the development
environment and determine what you by default compile against.
->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?
The compat libs for previous versions include the versioned libs
and old programs will automatically find them.
->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.
There could be a lot to chase here so I won't make guesses - one thing
at a time. Depending on what you were running before, it is possible
that we linked against a newer version of Inventor or some other library
that has now tickled something. Or, could be something entirely
_else_ - read on below.
Again, focus on resolving one thing at a time and don't assume it is
all related.
->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
What ???? I haven't! :-)
->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.
This is not good but could be a result of some other failure - like
a file didn't load and the app didn't deal with that failure in a graceful
way and this was the result.
->! PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "iv20"
->! PF Warning: pfdFindConverterDSO() - Could not load DSO for extension "iv"
This sez it couldn't load the DSO but it could be that the DSO is there but
not some other library that it needs. We don't get enough back from rld
to tell the difference for our print message. This could be that you need
to upgrade your verion of IL, IFL, or Inventor. To debug this,
setenv PFLD_LIBRARY_PATH .
setenv PFNFYLEVEL 9
run your app and you should get more verbose info.
My guess though is that we compiled against a newer version of some lib for
loeading textures that you don't have.
You can also run elfdump -L on any lib.so.# to see what libs it requires.
Different loaders have different requirements. We only put reqs on stuff
that does ship with IRIX, but that doesn't guarantee that you have it
installed on your system.
->! PF Warning: pfdLoadFile() - Unable to load file sun.wrl because of problem finding pfdLoadFile_wrl
->
->Looking at the installed products, I found:
->
This was a separate and known problem and the wrl loader is new in 2.2.
The trouble is that this loader fails becuase of a file it is looking for
in /usr/lib/ and the file is actually in /usr/lib/libpfdb/.perfLoader.wrl.
Link that into your /usr/lib to fix that specific issue.
->! 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.
They are included in the CD so for some reason they were not installed.
->
->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
Yes.
->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,
Definitely not - but hopefully from the above this is clear now.
->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.
I can't quite tell what you fixed here but don't mix your run-time version
problems with what cause causing objects to have bad shape.
A pfApp compiled with a lib.so.2 lib will
allways use a .2 lib or else it won't run at all.
What could cause bogus problems is if you have some object files of an app
compiled against one version of Performer and some object files
compiled against another. The versioning only gets done at the final
link. Different versions of Performer are NOT binary compatible
(which is why we did all of the versioning). So, if you mixed
compiles of object files of anything that included any Performer
header file, I'd expect you to see the garbage you describe.
At this point, I am guessing that this is what really happened to you.
So, you don't need separate directories for your run-time execution,
you need them for your compiles. However, do NOT start messing
with the links and directory structure because then future installs
will break you. If you need to be able to compile against different
versions of Performer, install them into different roots with the inst -r
option and when you compile set your $PFROOT to the right top level pfDir.
Note, this is NOT necessary for running the apps, just compiling.
If you have been doing a lot of potentially confused mixed compiles
on different machines with different versions without totally clobbering
before switching machines and versions, then at this point you probably can't
trust anything and should totally clobber and rebuild against one
clean version of Performer.
Again, I think that there should be a fairly straightforward
set of explainations to the problems you are having so if things
do not quickly become clear, please call the TAC to have someone
help walk you through things.
Good luck!
src.
--
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com (650) 933 - 1002 FAX: (650) 965 - 2658 MS 8U-590
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
=======================================================================
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