From: jan p. springer (jsd++at++igroup.org)
Date: 06/07/2001 00:51:56
brian and others,
that's a nice theory and i think your advise on how to link a loader is
correct. however doing nm -BCu on /usr/lib32/libpf.so gives you, among
other things:
...
3a25daf0 U iclose
...
3a25dac8 U iopen
...
but ldd /usr/lib32/libpf.so displays
libXmu.so => /usr/lib32/libXmu.so
libGLU.so => /usr/lib32/libGLU.so
libGL.so => /usr/lib32/libGL.so
libXsgivc.so => /usr/lib32/libXsgivc.so
libXext.so => /usr/lib32/libXext.so
libC.so.2 => /usr/lib32/libC.so.2
libCsup.so => /usr/lib32/libCsup.so
libXt.so => /usr/lib32/libXt.so
libX11.so.1 => /usr/lib32/libX11.so.1
libc.so.1 => /lib32/libc.so.1
libgen.so => /usr/lib32/libgen.so
libm.so => /usr/lib32/libm.so
libGLcore.so => /usr/lib32/libGLcore.so
libvice.so => /usr/lib32/libvice.so
libdmedia.so => /usr/lib32/libdmedia.so
libmutex.so => /usr/lib32/libmutex.so
so, iopen/iclose not being defined is an issue w/ libpf.so not being linked
against libimage.so (doesn't exist on any irix system i had a look at) or
having a funny link line itself not popping up a warning for unresolved
symbols (or the builder not acting on such a warning)?
can someone please clarify on these things? or did i miss the part in the
docs saying "when linking against libpf.so you also have to link against
libimage.[a|so]"?
[this is w/ performer 2.2/2.4 on irix]
j.
-- +------------------------------------+--------------------------------------+ | jan p. springer | jsd++at++igroup.org | | computer science, gmd.imk.ve | jan.springer++at++gmd.de | +------------------------------------+--------------------------------------+
This archive was generated by hypermail 2b29 : Thu Jun 07 2001 - 00:51:54 PDT