20

I have a 32-bit .so binary-only library and I have to generate 64-bit program that uses it. Is there a way to wrap or convert it, so it can be used with 64-bit program?

Krzysiek Goj
  • 1,598
  • 4
  • 16
  • 18
  • 1
    I was going to suggest recompiling the library code targetting 64bit, but get the impression you do not have the source to it...I am doubtful if a 64bit code can 'thunk' across to 32bit..maybe it can under linux's gcc? But then again this 'thunking' was a feature of Win95 (Remember that?) 32bit code calling 16bit code...have you tried linking the 64bit code referencing the 32bit dynamic library (.so) and running it? – t0mm13b Dec 22 '09 at 01:33
  • There is no "thunking" equivelent in any of the modern 64bit operating systems. This won't work. – Reed Copsey Dec 22 '09 at 01:42
  • Never tried that, but it might be possible by decompiling the library to c code, and then you might need to make some modifications. then compile it to 64bit... – Kapandaria Jan 29 '21 at 12:48

3 Answers3

31

No. You can't directly link to 32bit code inside of a 64bit program.

The best option is to compile a 32bit (standalone) program that can run on your 64bit platform (using ia32), and then use a form of inter-process communication to communicate to it from your 64bit program.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 3
    @Reed: Then how did Win95 manage the transition from 32bit code calling 16bit a la 'thunking' ? Was that at the assembler level to change around the stack pointer and registers? – t0mm13b Dec 22 '09 at 01:41
  • 7
    The OS handled this explicitly, but there is nothing that allows this in Linux or modern 64bit Windows operating systems, so you have to use a workaround like I posted. – Reed Copsey Dec 22 '09 at 01:42
  • @Reed: what IPC mechanism would you recommend? I think that shared memory should be reasonable faster then e.g. pipes or Unix Doman Sockets. –  Dec 24 '09 at 08:36
  • Well that's a shame. Thunking was a very useful technique and allowed you to be able to call 16bit dll's from 32bit apps, or in one case that I had I needed to call a 32bit dll from a 16bit app. It's unfortuante that the modern OS's don't provide that capability for 32/64bit code. I guess there is a reason for it... maybe complexity. – hookenz Apr 04 '12 at 00:44
  • 2
    x86_64 use a different calling convention than x86, as well as different number of regiters (double) makes it harder to link the 2 architectures all together – phuclv Aug 07 '13 at 08:10
5

For an example of using IPC to run 32-bit plugins from 64-bit code, look at the open source NSPluginWrapper.

Prof. Falken
  • 24,226
  • 19
  • 100
  • 173
Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
4

It is possible, but not without some serious magic behind the scenes and you will not like the answer. Either emulate a 32 bit CPU (no I am not kidding) or switch the main process back to 32 bit. Emulating may be slow though.

This is a proof of concept of the technique.

Then keep a table of every memory access to and from the 32 bit library and keep them in sync. It is very hard to get to a theoretical completeness, but something workable should be pretty easy, but very tedious.

In most cases, I believe two processes and then IPC between the two may actually be easiest, as suggested othwerwise.

Prof. Falken
  • 24,226
  • 19
  • 100
  • 173