c184-bp@rhombus.Berkeley.edu (Rick Braumoeller) (06/03/91)
I would like to know if there is an option to make the MIPS code linker 'ld' perform dead-code elimination when linking. Currently, I am developing a program that uses the gl library, and a few others, and the resulting object code is over 800K. It's my guess that the linker is just chucking all of the object code together without checking to see what actually needs to be there, because I can't imagine I'm using that much of GL. Our man pages here are not very reliable, so I can't draw any conclusions from them. Can someone "in the know" straighten me out? I am using version 2.0 of cc and ld. - Rick Braumoeller University of California, Berkeley
blythe@sgi.com (David R. Blythe) (06/04/91)
In article <C184-BP.91Jun2162911@rhombus.Berkeley.edu> c184-bp@rhombus.Berkeley.edu (Rick Braumoeller) writes: > > I would like to know if there is an option to make the MIPS code >linker 'ld' perform dead-code elimination when linking. Currently, I >am developing a program that uses the gl library, and a few others, >and the resulting object code is over 800K. > > It's my guess that the linker is just chucking all of the object >code together without checking to see what actually needs to be there, >because I can't imagine I'm using that much of GL. Our man pages here >are not very reliable, so I can't draw any conclusions from them. The linker by definition only pulls in the .o files from a library that are needed to fill unresolved references. The GL is big and lots of it needs to be present in order to have it run fast for all applications. With the addition of X11 as an integral part of the graphics system, your program will likely get even bigger. The only solution at the moment is to link with shared libraries, so that only one instance of the GL/Xlib code lives in memory. This also has the advantage that the binary file is smaller since the actual gl code is not present. Future releases of IRIX will see the removal of unshared libgl's and other libraries. In some ways this seems a bit of a loss, since it disallows the possibility of doing link-time optimizations involving the code in the shared libraries, but it does help save a lot of memory and disk space and even permits a certain amount of product independence. david blythe blythe@sgi.com