Hi all,

I have an interesting problem that I'm hoping someone may have already
encountered and solved. The issues concerns binding code compiled in the MPE
domain using CCXL to an archive library compiled with c89 and built with ar
in the POSIX domain.

BTW, I've looked at 5.0 Communicator articles relating to LINKEDIT
enhancements, POSIX Developers Toolkit manuals, C/iX manual, C library
manuals, and 3000-L archive, but haven't seen my specific questions
addressed. I have had an email exchange with the MPE Lab on this topic, but
they came back with a "I think" rather than a "I know" answer, so this query
(the Lab answer is below). General thoughts appreciated.

I have source code which has been ported to the POSIX domain using c89 and
ar to produce a ".a" library archive. The ported code allows users to
compile their code in the POSIX domain using c89 then statically link to the
library. Things work great for apps also built in the POSIX domain calling
the library built in the POSIX domain.

I'd like to make this library available for apps built in the MPE domain
using COBOL, CCXL, PASXL, etc. Instead of statically linking the library, at
run-time an XL would be specified. Users would compile either C or COBOL
code using MPE domain CCXL or COBOL compilers, link with LIBC(SHR?).LIB.SYS,
then run and specify the XL library via the RUN command ;XL= parameter.

One solution to creating this library is to copy and recompile all the
source code in the MPE domain. Ugh! Given the volume, source maintenance
issues, and structure, of the code I'd (REALLY!) rather not go that route.

What I'd like to do is short-circuit the process by using LINKEDIT to build
a MPE XL directly from the POSIX domain .a archive library.
Here are the steps I'm taking to build a MPE XL from a POSIX .a file:

!linkedit
buildxl FOOXL
addxl from="/TEST/PUB/lib/libfoo.a";share;merge;show;map
exit

I believe, but am not sure, that this approach is kosher. There have been
issues in the past with boundary conditions between libraries built using
MPE and POSIX compilers, but with introduction of shared variables in 5.0
I'm wondering if those problems (e.g. name collisions between /lib/lib* and
[log in to unmask] libraries) have gone away? I'm specifically concerned about
name collisions and externals references between code compiled with MPE CCXL
and POSIX c89.

Some specific questions:

1) Since the POSIX .a file is compiled using c89, should I be specifying a
dependent library list so that externals from the .a archive file will bind
to the POSIX library? In other words when I build the XL should I be
specifying "/lib/libc.a" (or shared library, see question #2?) as a
dependent library? Or will the proper binding "come out in the wash" when
the loader resolves externals at run time?

2) If I do specify a dependent library list I'm assuming I specify the
shared library from the POSIX domain (e.g. build fooxl;lib="lib/libc.sl"),
correct?

3) A user writes a C program and compiles, links (with LIBC.LIB.SYS etc.),
and runs under the CI in the MPE domain. All the C run-time MPE domain
libraries are RL's, so I'm assuming there won't be any surprises with the
code being linked to the POSIX library, correct?

4) Is the dependent library list used to only resolve externals in the XL it
is created with, or will the loader use the dependent libraries to also
resolve externals which the user might expect to be resolved in the MPE
system libraries (e.g. NL.PUB.SYS, XL.PUB.SYS)?

5) Anything else I haven't thought of?

BTW, HP's first answer was no it won't work cause one side is MPE and the
other side is POSIX and they were not built to "mix-n-match". I've heard
otherwise, so I'd really like a "I know" answer before committing to a lot
of pain and suffering.

Thanks for any and all pointers, thoughts, solutions, good vibes, etc.!

Lee Courtney
President

Monterey Software Group Inc.
1350 Pear Avenue, Suite J
Mountain View, California 94043-1302 U.S.A.
650-964-7052 voice
650-964-6735 fax

Advanced Authentication, Audit, and Access Control for HP3000 Business
Servers
http://www.editcorp.com/Businesses/MontereySoftware