HP 3000 Manuals HP 3000 Manuals
POSIX Libraries in XLs
by Bill Bennett
Commercial Systems Division
Intended Audience
With the introduction of Shared Globals it is possible to have POSIX C
programs use POSIX C executable library files (XLs). It is also possible
for POSIX and non-POSIX C programs to have externals restored by both
POSIX and non-POSIX XLs.
This article is intended for application developers, porters, support and
training personnel. The article provides an overview of how to create
and use XLs containing POSIX modules.
Please refer to the Communicator Overview article, "Introducing Shared
Globals on MPE/iX Loader", and the Technical article, "MPE/iX Shared
Globals Technical Overview", for a better understanding of Shared Globals
functionality.
Introduction
POSIX C requires global data to be accessible from the user program and
library functions. Before Shared Globals (sharing data between programs
and XLs) POSIX C applications could not be put into XLs; all POSIX
objects and libraries had to be linked into the program. Now with Shared
Globals it is possible to put POSIX libraries into XLs.
POSIX in XLs
Manipulating XLs can only be done with the Linkeditor. There are three
basic methods for putting POSIX modules into XLs. These methods are
detailed below. Also discussed is the mixing of POSIX and non-POSIX
modules and the caution that must be used when mixing modules.
POSIX and non-POSIX C use the same library calls, for example open().
The POSIX open() and the non-POSIX C open() are different; so there are
two open()s. XL.PUB.SYS contains the non-POSIX C library and the POSIX
RL (/lib/libc.a) contains the POSIX C library.
It is possible to have both POSIX and non-POSIX programs link with both
POSIX and non-POSIX XLs for shared services. But care must be taken to
make sure neither the program nor the XLs bind to the "wrong" code.
Wrong means that a POSIX function was inadvertently called by some
non-POSIX code or vice versa.
Method 1.
The most bullet proof method of adding POSIX modules to XLs is to link
the POSIX RL into each POSIX program and merge the POSIX RL into every
load module in an XL. The POSIX RL is released with its entry points
hidden so the POSIX code cannot be inadvertently called by non-POSIX
programs and load modules. But, to make sure the entry points are hidden
it is good practice to perform a HIDERL on the POSIX RL when creating
your XLs.
With all POSIX library entry points hidden, non-POSIX programs will bind
to the entry points of the non-POSIX libraries. This allows old
non-POSIX programs to work the same and allows POSIX programs to access
non-POSIX utilities in XLs (like database access). POSIX and non-POSIX
programs can access POSIX utilities in XLs. Also, since the POSIX
programs and XLs resolve all their own dependencies, they cannot be
harmed by any changes in the library link order.
With this method it is also possible to have POSIX and non-POSIX modules
in a single XL. The POSIX modules simply have to merge in the POSIX RL
and the non-POSIX modules do not.
For example,
_____________________________________________________________________
| |
| :COPY /lib/libc.a, LIBC |
| |
| :COPY /lib/libm.a, LIBM |
| |
| :COPY /lib/libsvipc.a, LIBSV |
| |
| |
| :LINKEDIT |
| |
| LinkEd> HIDERL RL=LIBC;ALL |
| |
| LinkEd> HIDERL RL=LIBM;ALL |
| |
| LinkEd> HIDERL RL=LIBSV;ALL |
| |
| LinkEd> LINK FROM=progo;to=prog;RL=LIBC,LIBM;XL=appxl;SHARE|
| |
| LinkEd> BUILDXL XL=appxl;LIMIT=10 |
| |
| LinkEd> ADDXL FROM=appo;RL=LIBC,LIBM,LIBSV;MERGE;SHARE |
| |
| LinkEd> ADDXL FROM=app2o;RL=LIBC;MERGE;SHARE |
| |
| LinkEd> EXIT |
| |
_____________________________________________________________________
NOTE In the previous example libm.a and libsvipc.a are used in addition
to libc.a. They are only required if the program or load module
call the functions they contain. In the later examples only libc.a
will be used but the other libraries could be used if necessary.
The Link Editor does not support HFS filenames so all examples
assume MPE filenames.
Method 2.
Another method of adding POSIX modules to XLs is to reveal the POSIX
library entry points in the application XL and bind the application
program to this one POSIX library. This method reduces program size and
makes updating the POSIX library simple because it is in only one place.
Only POSIX programs can call this XL. Any non-POSIX XL utilities must be
added to the XL list after the XL that contains the POSIX routines (appxl
in the below example.)
For example,
_______________________________________________________________
| |
| :COPY /lib/libc.a,LIBC |
| |
| |
| :LINKEDIT |
| |
| LinkEd> REVEALRL RL=LIBC;ALL |
| |
| LinkEd> EXTRACTRL ENTRY=_start;FROM=LIBC;TO=starto |
| |
| LinkEd> LINK FROM=progo,starto;to=prog;XL=appxl;SHARE|
| |
| LinkEd> BUILDXL XL=appxl;LIMIT=10 |
| |
| LinkEd> ADDXL FROM=appo;MERGE;SHARE |
| |
| LinkEd> ADDXL FROM=appo2;MERGE;SHARE |
| |
| LinkEd> ADDXL FROM=LIBC;MERGE;SHARE |
| |
| LinkEd> EXIT |
| |
_______________________________________________________________
NOTE _start needs to be in every program. (You can link all of libc.a
into the program but by just including _start the program size is
reduced.)
Method 3.
This last method is just a variant of the previous method. In this
method the POSIX RL is made into its own XL. This implementation is a
little more tricky because it requires a specific order in the XL list
(if additional XLs are necessary). This method reduces program size and
makes updating the POSIX library very easy because it is in a separate
file. Only POSIX programs can call these XLs. Any non-POSIX XL
utilities can only be added to the XL list after the POSIX XL (cxl in the
below example.) But problems may occur if a user uses XL= on the RUN
command or if an XL is missing.
For example,
___________________________________________________________________
| |
| :COPY /lib/libc.a,LIBC |
| |
| |
| :LINKEDIT |
| |
| LinkEd> REVEALRL RL=LIBC;ALL |
| |
| LinkEd> EXTRACTRL ENTRY=_start;FROM=LIBC;TO=starto |
| |
| LinkEd> LINK FROM=progo,starto;to=prog;XL=appxl,cxl;SHARE|
| |
| LinkEd> BUILDXL XL=appxl;LIMIT=10 |
| |
| LinkEd> ADDXL FROM=appo;MERGE;SHARE |
| |
| LinkEd> ADDXL FROM=appo2;MERGE;SHARE |
| |
| LinkEd> BUILDXL XL=cxl;LIMIT=10 |
| |
| LinkEd> ADDXL FROM=LIBC;MERGE;SHARE |
| |
| LinkEd> EXIT |
| |
___________________________________________________________________
NOTE The XL order is important, the POSIX XL must be last.
Constraints
Programs and libraries that wish to mix POSIX and non-POSIX C must adhere
to the following constraints:
1. No file descriptors may be shared across library boundaries. In
particular, file descriptors may not be passed as arguments to
functions in other libraries. For example a POSIX program cannot
open a file and then pass the file descriptor to a non-POSIX XL
function, expecting the function to access the opened file.
Exceptions to this constraint are files 0, 1, and 2 (stdin,
stdout, and stderr)
2. Environment variables may not be used for global data. The
getenv() function behaves differently in the two libraries.
3. The C pid (returned from getpid) may not be shared across library
boundaries. The libraries return different types.
Related Topics
For a complete description of the new Shared Global Data functionality
please read the HP Link Editor/iX Technical Addendum (32650-09476).
Please refer to the following Communicator articles for a better
understanding of Shared Globals functionality.
* "Introducing Shared Globals on MPE/iX Loader" in the "Application
Development" chapter for an overview of the Shard Globals benefits
and features.
* "MPE/iX Shared Globals Overview" in the "Technical Articles"
chapter for more detailed information about Shared Globals and its
related components.