From: Brian Furtaw (brian++at++sgi.com)
Date: 11/17/2000 06:38:01
If you want to change libimage to a shared library object you can.
Here's how,
ld -elf -shared -no_unresolved -rdata_shared -soname libimage.so -o
libimage.so -all /usr/lib32/libimage.a -lc
I took this command right from the `dso' manpage for reference.
Brian
Marco Petrone wrote:
>
> info-performer Mailing List wrote:
>
> >
> > From: Bram Stolk <bram++at++sara.nl>
> > Date: Mon, 13 Nov 2000 16:46:43 +0100
> > Subject: libpfdu.so depends on libvl.so
> >
> > Hello,
> >
> > This is about OpenGL|Performer on Irix, linux users can ignore this:
> >
> > libpfdu.so depends on libimage.a as it uses libimage's iopen().
> > Normally, this is not much of a problem: performer apps
> > link with -limage
> >
> > However, libimage is a static library, and libpf is a shared object.
> >
> > Now, if you develop your performer app as a shared object, to be
> > loaded by a foreign binary (let's say e.g. the python interpreter :-),
> > then things get screwed up.
> >
> > Because libpf has no shared reference to libimage, the application can
> > not pull in libimage code.
> >
> > Linking the custom shared Performer code with -limage does not help:
> > symbols from libimage.a are not used, thus not linked in.
> >
> > I've been able to fix this situation by converting libimage.a to
> > a libimage.so, which gives me a working setup, as the python-module
> > then refers to libimage.so, but this requires the .so version of
> > libimage to be available on both the build system and the runtime
> > system: this is bad, as this prohibits the proper working of my
> > program on foreign machines.
> >
> > My questions:
> >
> > -1- is there a smarter solution to this?
> >
> > -2- would there be any plans withing sgi, to augment Irix with
> > a libimage.so in the future?
> > What are sgi's criteria for releasing a lib as
> > static-only,shared-only, or in both forms?
> >
> > thx,
> >
> > Bram
> >
>
> I can confirm there are problems linking performer libraries to shared libraries. Some times ago I
> had a similar problem under Linux linking the pfTcl library and I solved it with the -Xlinker -E
> option. Now I had a problem trying to include a class making use of performer into the VTK library.
> VTK produces wrapping code for Tcl, python and Java. Up to now we worked with Tcl and I had no
> problems to include the performer class in the library with the following link option: -lpfdu_ogl
> -lpf_ogl. The VTK dynamic library is loaded fine from the wish shell with a "load vtktcl". The
> problem arose when I tried to create the dynamic object for python, since the "from vtkpython import
> *" resulted in unresolved symbols in the performer libraries. I finally solved with the following
> link options: -all -ljpeg -lpfdu -lpfui -lpfutil -lpf -lvl -limage. It seems (from a profane point
> of view) that the tcl and the python shells resolve symbols of the loaded dynamic objects in a
> different way, in particular the last one seems to need either the -all options and the explicit
> linking of all the libraries from which performer depends.
>
> Perhaps your problem is almost different, but I think they have a common origin.
>
> Marco.
--
----oOOo---- ----oOOo---- ----oOOo---- ----oOOo----
Brian Furtaw (brian++at++sgi.com)
Graphics Guru Office:(301)572-3293 Fax: (603)250-0370
12200-G Plum Orchard Drive OpenGL/Performer/OpenInventor/ImageVision
Silver Spring, Maryland 20904 Volumizer/Optimizer/React/PCI Device
Drivers
This archive was generated by hypermail 2b29 : Fri Nov 17 2000 - 06:39:42 PST