libgl.a questions

[Kurt Akeley]

In article <1991Apr24.155649.26399 at odin.corp.sgi.com>, kipp at warp.esd.sgi.com (Kipp Hickman) writes:
|> Ahem.  I don't know the answer to the first part - if systems without the
|> development option will be able to construct your application...However,
|> you can construct it yourself by linking it with the shared gl library.
|> Speaking of that, there will no lon|> ger be an unshared library in future
|> releases.  Its a bad evil nasty icky broken thing that should never have
|> been shipped because it leads to problems beyond belief.  In any case, if
|> you link your program with the shared gl it will run on ALL 4D pla
|> , thus (I am guessing) solving two problems with one solution.
|> 
|> So here is how you use shared libraries:
|> 
|> 	$(CC) -o whatever ... -lgl_s -lm -lc_s
|> 
|> and away you go.
|> 
|> 					kipp hickman
|> 					silicon graphics inc.
|> -----
|> My opinions are SGI's opinions, since everybody else is weasling out :-)

I'm not weasling out.  There are some problems that Kipp didn't mention.
A program compiled with a shared GL library will work on all 4D machines
running the same release, or a later release.  It typically will not work
on machines running an earlier GL release.  Also, code is portable from
machine to machine and release to release only if it makes only legitimate
GL calls in legitimate ways.  Since many illegitimate calls and call
sequences will work on a subset of machines and releases, careful coding
is required to insure portability.  The GL debugger, which will be available
in the 4.0 release, can be used to help insure portability, but there is
no substitute for careful coding with frequent referals to the manuals.

-- Kurt