Can 32-bit executable do explicit load of 64-bit shared library?

[Michael P. Smith]

Have many 32-bit legacy applications written in Microfocus COBOL that are being modified to call an API written in HP C (extended). Unfortunately, the API needs to call a 64-bit shared library so the API is 64-bit.

The various application groups refuse to convert to 64-bit code due to the amount of regression testing that would be required (8-12 months). Instead they have requested that the API be recompiled as 32-bit.

Which simply moves the linking issue from them to me. Being low man on the totem pole I can't push it back to them. So is it possible for a 32-bit executable to call a 64-bit shared library? If not, where is it documented so I can show upper management?


Thanks.

Michael P. Smith

[Steven E. Protter]

Shalom,

I'm resonably sure you can tell the program to load a library that is 64 bit.

I'm also reasonably sure that if the library does anything, even the slightest thing that involves 64 bit address space that the 32 bit executable will explode very nicely.

You can run a pure 32 application on a 64 bit OS. No problem with that. Trying to create a hybrid will probably cause problems.

Convert the 32 bit application to 64 bit, then all the calls in the library will work.

If the programmers didn't sue any 64 features in this fabled libarary, why is it 64 bit?

I rate the chances of this working as between slim and none.

SEP

[Michael P. Smith]

The vendor has supplied the library as 64-bit shared only and requires a business case to create a 32-bit library.

I've also found in the HP-UX 64-Bit Porting and Transition Guide, chapter 1, page 5:

"Linking 32-bit and 64-bit object files (.o, .sl, .a) together is not
supported. All modules in a program must be linked from either 32-bit
objects or 64-bit objects."

So it sounds like it isn't possible and I found my official documentation.

Of course, I find this AFTER posting my question ;) I'll leave the question open for a day or two incase someone proves this information to be false, or misinterpreted by me ;)

Thanks.

Michael P. Smith

[A. Clay Stephenson]

I have no idea where the documentation is. All I can say is try to link 32-bit and 64-bit modules and see how far you get. It won't be very far. I would just attempt to link a small mixed 32 and 64 bit application and let ld's stderr output suffice for the documentation.

In any event, there is a workaround but you aren't going to like it because it involves a major code rewrite. I've had to do this where both 32-bit and 64-bit libraries were simply not available and yet the application had to access for example database data for which there were only 64-bit libraries and an application toolkit thatwas only available in 32-bit form. You have to fork() into two processes and one of these then exec's a 32-bit executable. You can then communicate between the two halves via pipes. You can also mix 32 and 64 bit communication via shared memory but you have to follow the rules for this very carefully.

[Bill Hassell]

The business case is simple: 32bit programs that call 64bit libraries will have trashed stack values, pointers, data elements, in short, instant program crash. This is not just "unsupported", it is guarenteed to fail 100% of the time.

[Dennis Handly]

The answer is no. The tools will NOT let you do this.

>Bill: 32bit programs that call 64bit libraries will have trashed stack values,

You won't even get this far. The linker or dld will prevent this from even loading.

[rick jones]

As already pointed-out, one cannot mix 32-bit and 64-bit in the same executable.

Either the chicken has to go 64-bit, or the egg has to go back to 32-bit.

Or... not to hold-out false hope, and besides, migrating the legacy to 64-bit is the "correct" answer, how often is this boundary expected to be crossed, and how much 'state' in the 32-bit legacy has to be visible to the newer 64-bit stuff? If it is sufficiently infrequent and there is sufficiently little state shared between them, you could put the 64-bit parts into another process and communicate between the two via some form of IPC.

Not that it will help your situation, and I'm not sure when (is it even?) possible to have 64-bit COBOL, but if you get frustrated speaking with upper management, and want to say something career limiting :) you could point-out that the "time to migrate to 64-bit" clock started ticking in November of 1997 with the release of HP-UX 11.0...

[A. Clay Stephenson]

For even more career-limiting ammunition, you might try: "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." -- Edsger Dijkstra

Of course, closer to home for me (also from Dijkstra):"In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included."

----------------------------------------

Sadly, like reading Dilbert, it's plumb scary how much truth there is in these two observations.