Ross Scroggs ([log in to unmask]) wrote: : Now I've figured out why real Posix programs have to be linked with : /lib/libc.a: alarm, kill, fork, umask, fcntl, fstat, pause, waitpid, : mkfifo, pipe, dup2 ... are all unresolved otherwise. : OK. So, where's /lib/libc.sl? Am I correct in my understanding that : every Posix program can only be linked with a static copy of the library? : This should do wonders for memory pressure. What am I/HP missing here? : Thanks, When we first implemented the POSIX library on 4.5, the shared globals feature of the loader didn't exist, yet. We had to find a way to pass the errno global variable from the program file to the POSIX C functions in XL.PUB.SYS. We decided to do it by creating a "thin" RL for the POSIX C functions. These functions perform no real work except to pass some hidden "global" variables to the POSIX C library in XL.PUB.SYS. /lib/libc.a is nothing more than a set of interface routines. When a program is compiled and linked with c89, /lib/libc.a is treated as an RL by the linkeditor. Only those interface routines required by the program file are added from the RL. During the "shared globals" project, we discussed whether to restructure the POSIX libraries and create a /lib/libc.sl. At this time, we have no plans to create a /lib/libc.sl. Mike P. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Paivinen [log in to unmask] Hewlett-Packard CSY - Mailstop 47UP 19447 Pruneridge Avenue Cupertino, CA 95014