Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!msc@ramoth.SGI.COM
From: msc@ramoth.SGI.COM (Mark Callow)
Newsgroups: comp.sys.sgi
Subject: Re: Troubles with shared libraries!
Summary: a bug
Message-ID: <27805@sgi.SGI.COM>
Date: 2 Mar 89 20:35:52 GMT
References: <8903020325.aa27209@SPARK.BRL.MIL>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 41

In article <8903020325.aa27209@SPARK.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes:
> I have been continuing to have problems moving binaries between diffrent
> SGI platforms when they are compiled with shared libraries.  I consider
> being able to share binaries to be a highly desirable feature, and I
> intend to continue to "flog" this topic until something is decided.
> 
> I have modified the Cakefile so that all programs in the BRL-CAD Package
> are compiled (linked) with -lgl_s (when using LIBFB), -lm, and -lc_s.
> I still have problems when calling the routine ps_open_PostScript().

You have found a bug which is fixed in release 4D1-3.1 Rev D which was
released to manufacturing on Monday February 27th.  Volume shipments should
start within 30 days.

Incidently Rev D includes version 1.3 of 4Sight which has many bug fixes
and is much more solid than version 1.2.

Here are the gory details of Mike's problem.  You can stop reading here
if you don't care about them.
The GL uses libcps
to communicate with the window server.  We embedded the key pieces of libcps
in the GL so people with existing GL applications wouldn't have to change
their Makefiles to also link with libcps.  However these functions are
not exported from the GL.  When you link with a shared library and reference
a function that isn't exported (exporting means the function is in the shared
library's call table) the reference is resolved by calling to the address
of the function in the version of the shared library you are linking with.

When your program referenced ps_open_PostScript it ended up calling the
address of ps_open_PostScript in the shared GL you linked with.  It will
be in a different place on other machines and other releases of the shared
GL for the same machine.  Hence it breaks on these other machines.

I won't even try to explain the fix here.  It is very long and complicated.
The complexity comes from maintaining binary compatibility with GL applications
from previous releases.  In Rev D you will have to link programs that
use the GL and do their own PostScript stuff with -lgl_s and -lcps and
you will have binary compatibilty across all 3.1 Rev D machines.

--
	-Mark