From: Brian Corrie (bcorrie++at++origin1.imti.nrc.ca)
Date: 06/06/2001 07:18:37
Hi
I believe this might be a similar problem to one that was posted a few weeks
ago, although I can't remember the thread name. I replied to it so you can
search the list for my name perhaps...
If your DSO is being used as a loader, create the .so file with the
-no-unresolved command line argument to the loader. This should force all
unresolved symbols to be reported when the loader is compiled. Given that it
appears that you are linking with libimage then I suspect that this is
probably not the problem. That is, I suspect that your loader does not use
libimage directly so your linking to it with your loader may not actually get
you the symbol linked in. Does your loader use iopen???
I have experienced a similar problem when using a "non-standard" performer
application (something that is not perfly based 8-). Perfly (and most derived
work) links with libimage and therefore if a loader uses libimage and you use
it with perfly, no problem. The problem arises when you use an application
that does not link with libimage but uses a loader that does use the library.
If the loader does not use the -no-unresolved flag for compilation then you
will get the rld error you describe below. The Inventor loader (iv) I beleive
has this problem. Try creating a simple Performer app that loads a model file
and that does not link with libimage. Then try and load an iv file and see
what happens. I suspect that you will get the rld error as you described. This
may be what is happening in your case and the rld error may not have anything
to do with your loader at all...
So there are two solutions (or three maybe).
1) Make sure the loader you are building uses -no-unresolved
2) Make sure the application (if it is your own app) links to libimage
3) If neither of the above work (it is not your loader that uses libimage and
the application you are using is not yours to recompile) then you can try
writing a dummy function in your loader that uses iopen. This will hopefully
force the compiler to include it in your loader, so that other loaders can
also have access. This might move the symbols status from HIDDEN to DEFAULT???
I am not 100% sure if this will work or not but it might be worth a try if all
else fails...
Good luck,
Brian
> I'm posting this for a co-worker.
>
> ---------------------------------------------------------------------------
>
> I'm having troubles using a DSO with Performer and the Image Lib.
> I'm creating my own DSO with Performer and a few other objects.
> At runtime, I get a message "rld: Fatal Error: attempted to access
> unresolvable symbol in /usr/lib32/libpf_ogl.so: iopen"
>
> Looking through the Performer mailing list archives, I found that the
> Image
> Lib should be linked in. I do link with -limage, and the nm command
> shows
> the iopen symbol in the output. However, iopen has an attribute HIDDEN
> in my .so, whereas its attribute is DEFAULT in libimage.a. I'm guessing
> that this must be the reason iopen can't be resolved.
>
> Burrowing through the dso and ld man pages, I found the command
> "-exported_symbol" and made it apply to iopen. This had the affect
> of making iopen DEFAULT, but at runtime the app crashes with "killed"
> immediately.
>
> Anybody have any ideas or a better general way of creating the DSO
> than I've done?
>
> Thanks!
>
> jan
>
> ------------
> Jan A. Barglowski
> jan.barglowski++at++jntf.osd.mil
> Senior Graphics Programmer
> (719) 567-0845
> Wargame 2000
> Joint National Test Facility
>
> ---------------------------------------------------------------------------
> --------------00E0CD801E855A82947398A6
> Content-Type: text/x-vcard; charset=us-ascii;
> name="Bob.Buckley.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for 'Bwana'
> Content-Disposition: attachment;
> filename="Bob.Buckley.vcf"
>
> begin:vcard
> n:;
> x-mozilla-html:FALSE
> org:Raytheon Systems, Inc.
> adr:;;;;;;
> version:2.1
> email;internet:Bob.Buckley++at++JNTF.osd.mil
> title:Principal Software Engineer
> fn:'Bwana'
> end:vcard
>
> --------------00E0CD801E855A82947398A6--
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2b29 : Wed Jun 06 2001 - 07:20:57 PDT