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