libgl -G 0

[Archer Sully]

In article <8912210123.aa09940 at SPARK.BRL.MIL>, phil at BRL.MIL (Phil
Dykstra) writes:
> Dear SGI,
> 
> I am trying to dynamically link against libgl.a.  Using the -A option
> to ld, the files being linked in must have been compiled with -G 0.
> Since no such libgl was supplied, I decided to pop over to our source
> code and build one.  Then I found libgl didn't come with our source
> license!  What a bummer.  So, what's a guy to do?
> 
> [This is 3.2 on a 4D/25]
> 
> - Phil

You should have a G0 libgl.  Its in /usr/lib/libgl_G0, but it isn't 
a shared gl, so it may not be what you want.  If you don't have it,
get out your developers option tape and load it (its in a subsystem 
called 'dev.sw.G0libraries).

There is another answer, however.

ld -A takes an executable as an argument that contains the addresses of
all of the routines that won't be resolved in the link itself.  If you 
are planning to use the dynamically loaded modules with this executable
only, do this:

make a routine called dummy that looks like this

dummy(){winopen("")};

insert it into the main program somewhere.

Link your program with -lgl_s -lc_s.

Do your ld -A without any -l flags.  Since the target executable now has
the shared library jump table in it, ld will resolve any gl calls to that
copy of the jump table.  The same is true for the C library.  This could
cause some expansion of your executable, but from playing around with things
a bit I think that it actually works a bit bit better than G 0 libraries.  

Someday there may be a good way to do dynamic loading, but for now this
is it.  pity.

Archer Sully 	  | The Mind is a Terrible thing to Taste
(archer at sgi.com)  |		- Ministry