Shared library build using aCC

[doug pierson_1]

Hi HPers,

I have a working user exit written in C that I'm migrating to HP-UX11i. It runs correctly on Solaris, AIX, and on earlier versions of HP-UX. Building it on HP-UX11i requires my use of the "aCC" compiler. The initial component of the exit that is called is a shared library. Subsequently, it does a fork and exec of an executable. The executable then communicates with the shared library using IPC (shared memory and semaphores).

My symptom: The caller successfully finds and loads the shared library and starts correctly at the designated entry point. The fork call correctly returns a PID. However, I cannot see this PID when I do a "ps -ef". This seems rather suspicious. Furthermore, when I "execl()" to invoke the executable, it seems to never load, given that the first thing I do in its main() is a printf() that I never see. Yet, the execl() call returns no error to the shared library caller.

One wrinkle - I don't build the software that invokes my exit. It is a component of IBM's Websphere MQ messaging software called a Message Channel Agent (MCA). For any MQers out there, my exit is a channel message exit. You simply tell MQ the name, location, and entry point of the exit to be invoked. The MCA loads and runs the shared library beginning at the designated entry point.

I've never used the aCC compiler before, and I fear that my problem my occur because I'm not building my shared library correctly. Here's how I build the shared library. This output results from using the "+dryrun" option:

aCC: HP ANSI C++ B3910B A.03.33
/opt/aCC/lbin/ctcom.pa20 -DPLATFORM_UNIX -I. -I/opt/mqm/inc -I/opt/cb/build/pha
se2/api/inc -I/usr/include -I/usr/include/sys -piccode long -inst compiletime -d
iags 523 -D__HP_CXD_SPP=1 -D__hpux -D__unix -D__hppa -D__hp9000s800 -D__parisc -
D__STDCPP__ -D_ILP32 -D__HP_aCC=33300 -D_PA_RISC2_0 -D__STDC_EXT__ -D_HPUX_SOURC
E -D_INCLUDE_LONGLONG -ext on -lang c -exception off -I/usr/include -inline_powe
r 1 -longbranch 0 -unique_strings on -cachesize 256 cbchnex2sl.c
aCC: HP ANSI C++ B3910B A.03.33
LPATH=/usr/lib/libp:/usr/lib:/opt/langtools/lib
/usr/ccs/bin/ld -V -b +nosmartbind -o CBCHNEX2 /opt/aCC/lib/shlrt0.o +I__shlini
t -u__shlinit -v cbencfh.o cbunxipc.o cbchnex2sl.o -L /opt/cb/build/encryption -
L /opt/cb/build/entrust/tk/lib -L /usr/lib >/var/tmp/BAAa19829 2>/var/tmp/AAAa19
829
/opt/aCC/bin/c++filt &2
/opt/aCC/bin/c++filt removing /var/tmp/AAAa19829
removing /var/tmp/BAAa19829


Any help would be much appreciated!

Thanks,
Doug Pierson

Sr. Software Engineer
Systems Engineering, Inc.
dpierson@sengi.com
cell: 781-405-2000

[Paddy_1]

I am guessing "Interpositioning" might be the problem here though I am not sure.
Use the "-m" option to ld for a linker report that includes a note of symbols which have been intersposed.

[Steven Gillard_2]

There doesn't seem to be anything wrong with the shared library build. If its being loaded correctly by the caller then I suspect its ok.

My next step here would be to download a copy of the "tusc" utility and run a system call trace of the application so you can see the fork/exec sequence that is run.

You can get tusc from here:

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/tusc-7.3/

Regards,
Steve