loading a 32-bit library into 64-bit linux program

This is a discussion on loading a 32-bit library into 64-bit linux program within the Linux Programming forums, part of the Platform Specific Boards category; I know that there is a facility in linux to dynamically load a shared library into a process, but is ...

  1. #1
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590

    loading a 32-bit library into 64-bit linux program

    I know that there is a facility in linux to dynamically load a shared library into a process, but is it possible to load a 32-bit library into a 64-bit process? I have a library from a credit card processor, but it's 32-bit, and I need to use its functionality from a 64-bit program. For many months, I just had a separate program that runs in 32-bit mode and communicates through a pipe to the 64-bit process. This works great, but it is cumbersome and somewhat inconvenient, so I was hoping I could load the 32-bit library and use its functionality directly from my 64-bit process.

    any help would be greatly appreciated.

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Elkvis View Post
    I know that there is a facility in linux to dynamically load a shared library into a process, but is it possible to load a 32-bit library into a 64-bit process? I have a library from a credit card processor, but it's 32-bit, and I need to use its functionality from a 64-bit program. For many months, I just had a separate program that runs in 32-bit mode and communicates through a pipe to the 64-bit process. This works great, but it is cumbersome and somewhat inconvenient, so I was hoping I could load the 32-bit library and use its functionality directly from my 64-bit process.

    any help would be greatly appreciated.
    I don't think this is really supported on Linux. A 32-bit shared object will have 32-bit relocation entries as well as a 32-bit GOT and PLT. I don't see how the dynamic linker would be able to cope with that.

    Not that it isn't technically possible (it's possible on Windows for instance using WOW64 thunking, which the OS does automatically for you) but it just isn't implemented.

    I could be wrong.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    it seems you're right. since I wrote the post, I looked up the api info and wrote a simple test program to load a 32-bit lib from a 64-bit process and it does not work. the error returned is "wrong ELF class: ELFCLASS32"

    there has to be some way around this, so I'll keep looking, but at this point I've hit a dead end.

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Indeed, it is not supported. I was involved in the decision - at the edge, I didn't have much influence into it, but I was there at some of the discussion about the possible problems and solutions to those problems.

    Whilst technically it could be POSSIBLE to do (although the other way around would be more plausible), many things get VERY complicated - it's not too hard if all your data types are non-pointers, but it's very rare that libaries use ONLY int, char and floating point types, and never any pointers or arrays. [Because a 64-bit application WILL have addresses above 4GB, which will not fit in 32-bit pointer - for example the code and the stack are outside 32 bit range with the standard build system].

    That's before we discuss things like "how to fix up the offsets within the code" and such things.

    It is slightly easier to go the other way around - 64-bit DLL into a 32-bit application. It still requires a "thunking layer", but it's not quite as hard to achieve, because you only need to ensure that the memory allocated in 64-bit is within the 32-bit address range - and the Linux kernel has a special flag that says "the process is 32-bit so so don't give me memory outside of 4GB"].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    so what would you suggest as possible alternatives? the way I do it now works, but I'd like to make it a bit more transparent.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Elkvis View Post
    so what would you suggest as possible alternatives? the way I do it now works, but I'd like to make it a bit more transparent.
    There is no way to avoid running the 32-bit shared library in a separate process. One way or another you need to create a shim layer which handles the exchange of control.

    There ought to be a utility which takes a 32-bit library and wrappers it to produce a 64-bit thunking layer and do all this automatically for you. Unfortunately nobody has written one that I know of. Sounds like a project to put on my to-do list... as well as an excuse to buy a 64-bit box.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    Quote Originally Posted by brewbuck View Post
    There is no way to avoid running the 32-bit shared library in a separate process. One way or another you need to create a shim layer which handles the exchange of control.
    I'm probably going to write a new program to call the functions in the library, and pass data to it through a pipe as a JSON or XML object. the current program was hacked together (not by me) in a day and uses a prompt/response to get the data. it asks the parent process for a piece of data, and the parent provides it. I think this will be a bit better.

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Does your 64-bit program really benefit from being 64-bit. In most cases 64-bit is a little bit faster, but not so much that it's worth that much hassle... So maybe just compiling your app as 32-bit instead is a solution?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Oct 2007
    Posts
    32
    Quote Originally Posted by matsp View Post
    Does your 64-bit program really benefit from being 64-bit. In most cases 64-bit is a little bit faster, but not so much that it's worth that much hassle... So maybe just compiling your app as 32-bit instead is a solution?

    --
    Mats
    Or build shared library as 64-bit ?

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Valery Reznic View Post
    Or build shared library as 64-bit ?
    Yes, but that would require to have the source code, and reading between the lines in the first post, this is not available freely.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    Quote Originally Posted by matsp View Post
    the source code ... is not available freely.
    you are correct. on the other hand, the library does little more than construct an XML string, send it to a server thru an SSL connection, and receive the result. I can't imagine there's any proprietary code in there, with the possible exception of the hostname it connects to. I'm going to discuss with them the possibility of getting the source code. You never know - they might go for it if it helps them.

  12. #12
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Elkvis View Post
    you are correct. on the other hand, the library does little more than construct an XML string, send it to a server thru an SSL connection, and receive the result. I can't imagine there's any proprietary code in there, with the possible exception of the hostname it connects to. I'm going to discuss with them the possibility of getting the source code. You never know - they might go for it if it helps them.
    Or just ask that they rebuild it for 64-bit themselves.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 12-10-2004, 08:18 AM
  2. polymorphism - 64 bit - va_arg - advanced
    By anonytmouse in forum C Programming
    Replies: 2
    Last Post: 12-03-2003, 09:27 AM
  3. question about 32 bit addresses??
    By newbie02 in forum C++ Programming
    Replies: 3
    Last Post: 09-12-2003, 03:02 PM
  4. 16 bit or 32 bit
    By Juganoo in forum C Programming
    Replies: 9
    Last Post: 12-19-2002, 07:24 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21