Toolchain
The IRIX toolchain is a standard System V R4-style toolchain. This page details its behaviours, components and uses.
| IRIX Toolchain Components | |||
| Tool | Task | Command | |
| Compiler Driver | Compile, link, and load programs | cc,CC,f90,f77,as | |
| Object file analyzer | Analyze object files | dis, dwarfdump, elfdump, file, nm, size | |
| SpeedShop/WorkShop | Analyze program performance | cvperf, prof, sscompare, ssrun. | |
| Archiver | Produce object-file libraries | ar | |
| Linker | Link object files | ld | |
| Runtime linker | Link DSOs at runtime | rld | |
| Debugger | Debugs programs | cvd, dbx | |
For the various ABIs, here are the primary search paths:
- O32 - /usr/lib, /lib, and /usr/local/lib
- N32 - /usr/lib32, /lib32, and /usr/local/lib32
- N64 - /usr/lib64, /lib64, and /usr/local/lib64
IRIX LD
The IRIX linker is a traditional linker, unlike GNU ld. The basic implication of this is:
When processing modules on the command line, the IRIX ld requires that at least one reference to an unresolved symbol appear before inclusion of the library that resolves that reference. GNU ld uses a multi-pass algorithm to resolve undefined symbols, and so lets the developer specify libraries in an arbitrary order.
Linking Shared Objects/Libraries
When a dynamically linked executable is ran, the run-time linker, rld, identifies the libs required by the executable and loads the required libs. If necessary the IRIX kernel relocates libs within the process' virtual address space, so that no two libs occupy the same location. The program header of a dynamically linked executable contains a field, the liblist, which lists the libs required by the executable.
When looking for a lib, rld searches directories in a specific sequence:
- /usr/lib{32,64}
- /usr/lib{32,64}/internal
- /lib{32,64}
- /lib/cmplrs/cc (only for O32)
- /usr/lib/cmplrs/cc (only for O32)
- /opt/lib{32,64}
The brackets show variants for N32/N64 ABIs.
RPATH is a colon-separated list of directories stored in the main executable. One can set RPATH by using the -rpath argument to ld:
This example links the program against libmylib.so in the current directory and configures the executable such that rld searches the directory /d/src/mylib when searching for libs.
The LD_LIBRARY_PATH environment variable is a colon-separated list of directories to search for libs. This can be very useful for testing new versions of libs before installing them in their final location.
The equivalents for N32 and N64 are: LD_LIBRARYN32_PATH and LD_LIBRARY64_PATH respectively.
Runtime Symbol Resolution
IRIX uses a program called rld to link shared executables at runtime to linked libraries.
Dynamically linked executables can contain symbol references that are not resolved before run time. Any symbol references in the main program or in an archive must be resolved at link time, unless one specifies the -ignore_unresolved argument to cc.
Libs may contain references that are not resolved at link time. All data symbols must be resolved at run time. If rld finds an unresolvable data symbol at run time, the executable exits with an error. Text symbols are resolved only when they are used, so a program can run with unresolved text symbols, as long as the unresolved symbols are not used.
Ranlib
IRIX does not use ranlib when using the MIPSPro/IRIX Toolchain. Ranlib operations are done by the linker. For information, the Techpubs link here is fantastic: https://techpubs.jurassic.nl/manuals/0650/developer/Cplr_PTG/sgi_html/ch03.html
GNU LD
GNU LD and AS can be used on IRIX, but only older binutils releases support them. There's also questionable issues with symbol resolution and more.
Larger binaries usually result, and GNU ranlib must be used to satisfy the linker code. Additionally GNU ld lacks hooks into rld, so there are chances rpath for rld will not work correctly, and as a result programs using shared libraries may have slower startup times.