shl_load / shl_findsym problem with Cobol Shared Libraries

[J. Orte]

We have a big problem with shl_load and shl_findsym.

We have a large quantity of Cobol .sl libraries compiled with Microfocus, which we load dinamically with shl_load.

Everything worked together in a HP-UX 10.20 system and we are doing the recompilation to HP-UX 11.11 in 32 bits.

The code looks like this:

(MID_ID_T *,void *, void *,short *,long *) funLlama;
handle=shl_load(NomDll,BIND_IMMEDIATE | BIND_NONFATAL, 0L);
if (handle!=NULL) {
sRet = shl_findsym(&handle, tSimbol, TYPE_PROCEDURE, (void *) &funLlama);
if (sRet == 0) {
sRet = (*funLlama)(&uId,(void *)pMsjBin, (void *)pMsjRetBin, &sNumMens,&sTipMens);
}
}

It works until we want to execute the external "funLlama" procedure.

I have done my homework looking for a solution in this great forum, and I almost everything I found, but without success...

Can anyone help me? Any ideas?

Thanks in advance.

Jordi

[ranganath ramachandra · Accepted solution]

so what exactly happens when you execute the procedure ?

[J. Orte]

Oh! Sorry!

I get a "Segmentation Fault" (SIGSEVR signal).

Jordi

[Stephen Keane]

1. What is tSimbol set to? (is that a deliberate typo?)

2. Try it without the BIND_NONFATAL and see what happens.

[J. Orte]

This are my answers...

1) It contains "START9000" which is defined as then PROGRAM-ID at the Cobol program. It worked before at HP-UX 10.20....

2) Without BIND_NONFATAL I get the error "ENOSYM" after the execution of shl_load, both using BIND_IMMEDIATE or BIND_DEFERRED. In the HP-UX 10.20 only BIND_DEFERRED was used but I tried with "BIND_IMMEDIATE | BIND_NONFATAL" because this was the only way I didn't get an error after trying to load the library.

Thanx.

[ranganath ramachandra]

--------
2) Without BIND_NONFATAL I get the error "ENOSYM" after the execution of shl_load, both using BIND_IMMEDIATE or BIND_DEFERRED. In the HP-UX 10.20 only BIND_DEFERRED was used but I tried with "BIND_IMMEDIATE | BIND_NONFATAL" because this was the only way I didn't get an error after trying to load the library.
---------

are you sure? BIND_DEFERRED should leave the symbol binding for later, so you seem to be saying it reverse.

you should try to resolve the ENOSYM first. it is possible that your library depends on something external (say something in libc or cobol runtime libraries) that changed between 10.20 and 11.11.

an easy way to get an error message from dld about which symbol caused ENOSYM - just link the program directly with the library (or LD_PRELOAD it) and run it, you may see an error at startup.

please also make sure you have the latest linker/loader patches installed.

[J. Orte]

Yes, it's true. With BIND_DEFERRED We get the ENOSYM error when we try to execute the procedure loaded at "funLlama".

We have tried "shl_load" with new simple C and Cobol built shared library and It works only in C (both are "Hello World" like simple programs...).

As a result, we are working on the "update patch" solution...

Thank you again.

Jordi

[J. Orte]

Finnally it was a problem with the cobol compiler. Shared Libraries were incorrectly generated.

Thanks for your time!

Jordi

[J. Orte]

-- closed --