james@adt.UUCP (james cerrato) (04/23/91)
We ship a graphics product to clients using many different SGI machines, running diffent releases of IRIX. In order to deliver the product without first having built the executable on each configuration [Hardware/OS] first, we just ship a library of our object files. Then our installation script links our library with -lgl at the client's machine. Will this strategy work even on machines that do not have installed the development option? Also if anyone can give me information on how to use shared libraries, and what the benefits are, or a pointer to where to find information about them in the manuals it would be greatly appreciated. Thanks for your time. James Cerrato Associative Design Technology Westboro MA adt!james@bu.edu NOT FADE AWAY NOT FADE AWAY
kipp@warp.esd.sgi.com (Kipp Hickman) (04/24/91)
In article <9104231603.AA15231@noname>, james@adt.UUCP (james cerrato) writes: |> We ship a graphics product to clients using many different SGI machines, |> running diffent releases of IRIX. In order to deliver the product without |> first having built the executable on each configuration [Hardware/OS] first, |> we just ship a library of our object files. Then our installation script |> links our library with -lgl at the client's machine. Will this strategy |> work even on machines that do not have installed the development option? |> |> Also if anyone can give me information on how to use shared libraries, |> and what the benefits are, or a pointer to where to find information about |> them in the manuals it would be greatly appreciated. |> |> Thanks for your time. |> |> James Cerrato |> Associative Design Technology |> Westboro MA 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 longer 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 platforms , 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 :-)
kurt@cashew.asd.sgi.com (Kurt Akeley) (04/25/91)
In article <1991Apr24.155649.26399@odin.corp.sgi.com>, kipp@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
drb@eecg.toronto.edu (David R. Blythe) (04/29/91)
In article <1991Apr24.171552.28289@odin.corp.sgi.com> kurt@cashew.asd.sgi.com (Kurt Akeley) writes: >In article <1991Apr24.155649.26399@odin.corp.sgi.com>, kipp@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. [Sorry this is a followup to kipp's not kurt's posting] ... Does this mean pixie will work with shared libraries? This sort of seems unlikely since pixie is pretty grungy, but I believe Jim Barton did mention that pixie was rewritten ... Anyway if it doesn't I hope the unshared library will stay for measurement/tuning purposes. -drb