April 13, 2005, 8:53 AM — Definitely NOT one of the first dozen Unix commands that a person learns, the crle command is so infrequently discussed in the hallways of software development companies that even I don't know how to pronounce it. Is it "see are elle ee" (phonetically "si ar el i") or am I supposed to say "curly"? After all, Unix offers few clues in such matters. We have the likes of vi ("vee eye" and awk (which rhymes with "talk") as two of many examples illustrating that there is no general pronunciation rule that governs our favorite OS. But, fortunately, since I don't have to read this column to you, let's move on to the more important issue -- what does this command do and how can you use it in managing your systems?
To begin with, crle stands for "configure runtime linking environment". It is a command that allows Solaris sysadmins to better manage their dynamic linker. Specifically, it allows you to configure library paths so that programs run on a system will have as easy access to shared library files in locations like /usr/local/lib or /opt/lib as they do to /usr/lib. Instead of configuring a LD_LIBRARY_PATH to give these lib directories visibility, you run the crle command and augment the load library path on a system-wide basis. In other words, the crle command is basically the equivalent of updating ld.config.
What's Configured Now?
To view the system library path on a Solaris system, you can issue the crle command on a line by itself:
# crle Default configuration file (/var/ld/ld.config) not found Default Library Path (ELF): /usr/lib (system default) Trusted Directories (ELF): /usr/lib/secure (system default)
Notice that, in the absence of an ld.config file, a limited library search path is established containing only /usr/lib for normal usage.
This library path setting is independent of any paths you may have added to your LD_LIBRARY_PATH interactively or through settings in your dot files. The paths shown are the paths that binaries on your system will use regardless of the LD_LIBRARY_PATH setting.
How to Configure New Paths
To add a new path to your dynamic linker, you would use the crle -l command, but this command overwrites the existing path. In other words, you need to repeat the existing path elements so as not to remove them. For example, you might type the following command to add /usr/local/lib to what is shown above:
# crle -l /usr/lib:/usr/local/lib
Afterwards, you should verify the new settings:
# crle Configuration file [2]: /var/ld/ld.config Default Library Path (ELF): /usr/lib:/usr/local/lib Trusted Directories (ELF): /usr/lib/secure (system default) Command line: crle -c /var/ld/ld.config -l /usr/lib:/usr/local/lib
What should you do if You Break It?
If you type your crle command carefully, you should have an easy time augmenting your dynamic loader's search path. If, on the other hand, you break the path -- for example, by typing crle -l followed only by the paths you intend to add -- you can send your Solaris system into a very troublesome state. The reason is simple; just about every command that you type on your Unix system depends on shared object files stored in /usr/lib -- including commands as benign as ls. So, if /usr/lib disappears from your linker's search path, your ability to work wonders on the command line will come to an abrupt end -- at least until you type the command again. The breakage will be illustrated with errors such as this:
$ ls ld.so.1: ls: fatal: libc.so.1: open failed: No such file or directory Killed
Normal Unix command functionality can be restored by typing a second crle command. While you could also fix the problem for yourself by setting your LD_LIBRARY_PATH as shown below, this wouldn't help anyone else who logs into the system.
LD_LIBRARY_PATH=/lib:/usr/lib;export LD_LIBRARY_PATH
Typing the crle command with the complete library path should fix the problem immediately and easily -- except when you can't issue it.
What should you do if You Break It with sudo?
A second crle won't help you out of the pit that you inadvertently created if your super powers are bequeathed through sudo. In this case, you won't be able to reproduce the linker's path with a "sudo crle" command because sudo itself depends on /usr/lib.
$ sudo crle -l /lib:/usr/lib:/usr/local/lib ld.so.1: sudo: fatal: libdl.so.1: open failed: No such file or directory Killed
In fact, remote access to the box will also fail because telnet, ftp and ssh will try to access shared libraries which are no longer in the path.
