install package/library for both 64-bit and 32-bit Linux systems

This is a discussion on install package/library for both 64-bit and 32-bit Linux systems within the Linux Programming forums, part of the Platform Specific Boards category; Hi, My HOME at a server is loaded into a local computer via NFS. My server is a 64-bit Linux ...

  1. #1
    Registered User
    Join Date
    Jan 2009
    Posts
    159

    install package/library for both 64-bit and 32-bit Linux systems

    Hi,
    My HOME at a server is loaded into a local computer via NFS. My server is a 64-bit Linux while my local is a 32-bit Linux.

    Is it true that: If I compiled my C/C++ program on 64-bit OS, then it can be linked to either 64-bit library or 32-bit library and if I compiled my program on 32-bit OS, then it can be linked only to 32-bit library, regardless static or shared library?

    So if I want to build some C/C++ libraries from source under my HOME so that they can be linked to my program running on either my server or local, I have to build them on the 32-bit local but not on the 64-bit server?

    What will the difference be if my program on the 64-bit server is linked to a 32-bit library compared to being linked to a 64-bit library? Is the former slower than the latter?

    I installed emacs under my HOME on the 32-bit local and it can be run on both 32-bit local and 64-bit server. I used ldd to see what shared libraries it is linked to. The output is different on the local side and on the server side. There is one more .so file for the server than for my local. For the rest common 20 .so files, the numbers I assume to be addresses are different, e.g.on the server:
    libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00d26000)
    and on my local:
    libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00a46000)
    Is it true that each of these .so files each has two parts inside itself: one for 32-bit local and one for 64-bit server, which can be linked to using different addresses? How can I build C/C++ libraries so that the .so files can act like that?

    Thanks and regards!
    Last edited by lehe; 04-30-2009 at 07:18 PM.

  2. #2
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    (assuming you're talking about x86 and amd64 architectures for 32- and 64-bit here, respectively...) My understanding is that a 64-bit executable must be linked to 64-bit static or shared libraries, and that a 32-bit executable must be linked to a 32-bit static or shared library. Now, 32- and 64-bit libraries can coexist on the same system - see /lib32, /lib64, and the /usr equivalents. Additionally, a 32-bit executable linked with 32-bit libraries will still run in on amd64 architectures.

    That said, since most things in Linux are open source, you can compile them for 64-bit, if that's what your architecture is.

    Edit: Ooh, post count at 666. Lucky.

    Edit: Ah, and your last question. No, I do not think that .so files can have a 64-bit and a 32-bit all in the same .so file. Otherwise, why would we have /lib32 and /lib64?
    Last edited by Cactus_Hugger; 04-30-2009 at 08:46 PM.
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  3. #3
    Registered User
    Join Date
    Jan 2009
    Posts
    159
    Thanks!

    My local computer is:
    Linux 2.6.9-78.0.13.ELsmp #1 SMP Wed Jan 14 16:12:46 EST 2009 i686 i686 i386 GNU/Linux
    My office server is:
    Linux 2.6.9-78.0.8.ELsmp #1 SMP Wed Nov 19 19:42:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
    My local is not x86 and my server is not amd64. Why does it matter?

    Actually on the 64-bit server my program can be linked to the static libraries built on the 32-bit local.

    On the server, there are /lib and /lib64 under /usr. Is /lib what you mean by /lib32?

    If it cannot be that a 64-bit and a 32-bit all in the same .so file, why emacs was linked to the same .so files on local and server?

  4. #4
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    amd64 and Intel 64-bit chips are compatible. (The Gentoo, Ubuntu, Debian, and for all I know, others, use amd64 to apply to Intel's chips as well.) Same things apply.

    Then you lack the 32-bit lib folder, and cannot run 32-bit software. On your machine, lib is likely a symlink to lib64. Here's an ls of my root:
    Code:
    / $ ls 
    bin   dev  home  lib32  lost+found  mnt  proc  sbin  tmp  var
    boot  etc  lib   lib64  media       opt  root  sys   usr
    The lib folder is a symlink to /lib.

    Let's take skype - skype, being proprietary and produced by a slow company, is only available in 32-bit. It is running, and I can see that it is using the 32-bit libraries:
    Code:
    / $ cd /proc/`pidof skype`
    /proc/7412 $ cat maps | grep .so | head -n 10
    f6caa000-f6cf8000 r-xp 00000000 08:03 131790                             /usr/lib32/libpulse.so.0
    f6cf8000-f6cf9000 r-xp 0004d000 08:03 131790                             /usr/lib32/libpulse.so.0
    f6cf9000-f6cfa000 rwxp 0004e000 08:03 131790                             /usr/lib32/libpulse.so.0
    f6cfa000-f6cfe000 r-xp 00000000 08:03 654465                             /usr/lib32/alsa-lib/libasound_module_ctl_pulse.so
    f6cfe000-f6cff000 r-xp 00004000 08:03 654465                             /usr/lib32/alsa-lib/libasound_module_ctl_pulse.so
    f6cff000-f6d00000 rwxp 00005000 08:03 654465                             /usr/lib32/alsa-lib/libasound_module_ctl_pulse.so
    f6e3e000-f6e41000 r-xp 00000000 08:03 793095                             /lib32/libcap.so.1.10
    f6e41000-f6e42000 rwxp 00002000 08:03 793095                             /lib32/libcap.so.1.10
    f77c6000-f77cf000 r-xp 00000000 08:03 290575                             /lib32/libnss_files-2.8.so
    f77cf000-f77d0000 r-xp 00008000 08:03 290575                             /lib32/libnss_files-2.8.so
    Now, if I do any other app on my system:
    Code:
    /proc/5210 $ cd /proc/`pidof rhythmbox`
    /proc/32040 $ cat maps | grep .so | head -n 5
    7fbc2c5ef000-7fbc2c609000 r-xp 00000000 08:03 2199507                    /usr/lib64/libvorbisenc.so.2.0.4
    7fbc2c609000-7fbc2c808000 ---p 0001a000 08:03 2199507                    /usr/lib64/libvorbisenc.so.2.0.4
    7fbc2c808000-7fbc2c809000 r--p 00019000 08:03 2199507                    /usr/lib64/libvorbisenc.so.2.0.4
    7fbc2c809000-7fbc2c9c8000 rw-p 0001a000 08:03 2199507                    /usr/lib64/libvorbisenc.so.2.0.4
    7fbc2c9c8000-7fbc2c9d8000 r-xp 00000000 08:03 2248665                    /usr/lib64/gstreamer-0.10/libgstvorbis.so
    Now, if I ldd rhythmbox, I get results in both /usr/lib and /usr/lib64, despite them being the same directory.

    Actually on the 64-bit server my program can be linked to the static libraries built on the 32-bit local.
    You are mistaken. Here's a small program, hi, that calls a function in libhi.so.0: (the function prints Hello World...) If I'm on my 32-bit machine, all is well. If I compile everything 64- or 32- bit on the 64-bit machine, all is well. If I try to mix:
    Code:
    ~/code/lib3264 $ objdump --file-headers ./hi | grep format
    ./hi:     file format elf32-i386
    ~/code/lib3264 $ objdump --file-headers ./libhi.so.0 | grep format
    ./libhi.so.0:     file format elf64-x86-64
    ...and then try to run:
    Code:
    ~/code/lib3264 $ ./hi
    hi: Success
    Error: ./libhi.so.0: wrong ELF class: ELFCLASS64
    Failed to open .so!
    (Ignore the success line -- dlopen does not set errno it turns out...) Basically: 32-bit exe trying to open 64-bit .so - fails with that message.
    The code:
    Code:
    // hello_lib.c
    #include <stdio.h>
    
    extern void hello()
    {
    	printf("HI THERE\n");
    }
    Code:
    // hello.c
    #include <stdio.h>
    #include <dlfcn.h>
    
    int main()
    {
    	void (*hf)(void);
    	void *dll;
    
    	dll = dlopen("./libhi.so.0", RTLD_NOW);
    	if(!dll)
    	{
    		perror("hi");
    		fprintf(stderr, "Error: %s\n", dlerror());
    		fprintf(stderr, "Failed to open .so!\n");
    		return 1;
    	}
    	hf = dlsym(dll, "hello");
    	(*hf)();
    	dlclose(dll);
    	return 0;
    }
    Code:
    $ gcc -fPIC -shared -o libhi.so.0 hello_lib.c
    $ gcc -o hi hello.c
    Edit: Think about it this way: If I could load a 64-bit DLL into a 32-bit program... how would the DLL return a pointer? (A very common operation.) The 32-bit program would expect the pointer to be ... 32-bit. But the 64-bit program...
    Last edited by Cactus_Hugger; 04-30-2009 at 11:50 PM.
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Indeed, we can't use 64-bit libraries with 32-bit apps, or 32-bit libraries with 64-bit apps. Not only would the pointer size not work, but also, the calling convention for 64-bit uses registers that don't even exist in 32-bit (R8-R15) - how is the 32-bit app supposed to fill in the registers that it doesn't even have? [1]

    It is entirely possible to install a 64-bit and a 32-bit library on the same machine and use 32-bit apps on a 64-bit machine. As described above, there is usually a /usr/lib64 for 64-bit libs, and either /usr/lib or /usr/lib32 that holds 32-bit versions of libs. You just have to install the 32-bit library, if it's not there already.

    [1] Of course, if the processor is 64-bit capable, the hardware for those registers DOES exist, but you can't get to them without entering 64-bit mode, which is only possible inside the kernel, and once you switch, it's quite messy to switch back [all of the page-table that controls with memory locations are accessible etc is different, for example]. So we don't want to switch back and forth very much.

    Note that once in 64-bit mode, it is fairly easy to switch to 32-bit compatibility mode, where an application can run 32-bit code.

    --
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. 32 bit to 64 bit Ubuntu
    By Akkernight in forum Tech Board
    Replies: 15
    Last Post: 11-17-2008, 03:14 AM
  2. 32 bit or 64 bit allignment ?! gcc options??
    By mynickmynick in forum C Programming
    Replies: 3
    Last Post: 07-29-2008, 03:43 AM
  3. Replies: 16
    Last Post: 11-23-2007, 01:48 PM
  4. porting application from 32 bit to 64 bit error
    By gandalf_bar in forum Linux Programming
    Replies: 1
    Last Post: 09-14-2005, 10:20 AM
  5. Porting from 32 bit machine to 64 bit machine!
    By anoopks in forum C Programming
    Replies: 10
    Last Post: 02-25-2005, 08:02 PM

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