Progress dld error on HP-UX 11.00

[T Dockery]

Legacy system with HP-UX 11.00 on PA-RISC, Progress 9.1B.

This system has seen little use over the last couple of years. Recently, when a user tried to use the _progres executable, the following error was generated:

/usr/lib/dld.sl: Unresolved symbol: __head (data) from /usr/lib/libC.2
/usr/lib/dld.sl: Unresolved module for symbol: __shlinit (code) from /usr/lib/libstream.2
ABORT instruction

Thing is, it used to work. I tried applying the latest linker patch, PHSS_35380, but no love.

This system is, naturally, off support with both HP and Progress.

I ran ldd, and got:
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libdld.2 => /usr/lib/libdld.2
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libm.2 => /usr/lib/libm.2
/usr/lib/libstream.2 => /usr/lib/libstream.2
/usr/lib/libCsup.2 => /usr/lib/libCsup.2
/usr/lib/libC.2 => /usr/lib/libC.2
/usr/lib/libcl.2 => /usr/lib/libcl.2
/usr/lib/libisamstub.1 => /usr/lib/libisamstub.1
/usr/lib/libdld.2 => /usr/lib/libdld.2

Ideas?

[Dennis Handly]

>when a user tried to use the _progres executable, the following error was generated:
/usr/lib/dld.sl: Unresolved symbol: __head (data) from /usr/lib/libC.2
/usr/lib/dld.sl: Unresolved module for symbol: __shlinit (code) from

This indicates an illegal mixing of obsolete cfront (__head and libC.2) and aC++.

>it used to work.

I can't see how. _progres should never have been linked with -lC.

About the only way you can make it work is to compile an empty .c file, create a shared lib libC.2, and point SHLIB_PATH to that file.

[T Dockery]

The thing is, it *did* work. This is a commercial product, so we don't have access to the source to recompile and link.

[Dennis Handly]

>This is a commercial product

I don't see how with that mistake, unless dld's smart bind was dumbed down?? I've seen similar unsats caused by incorrect directions from some database vendor.

>so we don't have access to the source to recompile and link.

I suggested how to fool it by creating a dummy libC.2. (Assuming that it doesn't really need the contents of that lib.)

[T Dockery]

>>This is a commercial product

>I don't see how with that mistake, unless dld's smart bind was dumbed down?? I've seen similar unsats caused by incorrect directions from some database vendor.

And there's the gist of the problem. This was working, it quit at some point.

Because it's a legacy system, it's hard to pinpoint when it quit working. My hypothesis at this point is that an OS patch did it, but I can't prove that. Sadly, because the system is tight on space, there is no rollback available on the patches applied months ago. Also, just to add insult to injury, the DLT library died last week...

>I suggested how to fool it by creating a dummy libC.2. (Assuming that it doesn't really need the contents of that lib.)

Sorry, I missed that suggestion on my first reading. Can that be done with the gcc compiler? The aCC compiler is not available on this box. We do have aCC on some other 11i servers, don't know if that would help on an 11.0 system.

Thanks for the feeback so far.

[Dennis Handly]

>My hypothesis at this point is that an OS patch did it

I assume it could only be a dld patch.

>Can that be done with the gcc compiler?

You can use the bundled C compiler to compile an empty file.