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