32Bit dynamic library is actually static
by coltson from LinuxQuestions.org on (#5KSDW)
Hello. I recently built the Alsa library. Usually it creates both static and dynamic versions of it. When I built a 64bit version, it worked as expected. However this time I built a 32bit version.
As soon as the building and installing processes were done, I notice that the install folder size of was much smaller than the 64bi version (1.6mb against 4.7mb). So something went wrong. Investigating al ittle more, I executed ldd on ibasound.so. And the result? Code:not a dynamic executableObviously it should show something like the 64bit version shows:
Code:linux-vdso.so.1 => (0x00007fffc03ff000)
libm.so.6 => /lib/libm.so.6 (0x00007fd779958000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fd779754000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fd779536000)
librt.so.1 => /lib/librt.so.1 (0x00007fd77932e000)
libc.so.6 => /lib/libc.so.6 (0x00007fd778fab000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd779ed1000)The overall reason behind this weird behavior is also quite obvious> I am adding 32bit from the scratch to my system, piece by piece. First I compiled a gcc with 32bit support, installed it in some non default dir, removed the old gcc and then created symbolic links to the new on Code:/usr/local/binAfter that, I created a dir called /usr/lib32 and then I created a sym link to the 32bit version of libstdc++ on it.
More or less about the same time, I also compiled and installed in a non default dir, a 32bit version of glibc
Then I finally went to compile a 32bit version of alsa. First, configure complained about incompatible version of libc.a and libc.so. I then created symbolic links to the 32bit version of them on Code:/usr/lib32. It then complained about some files: Code:crt1.0 crti.o crtn.o I did the same for them. Finally, it complained about Code:libm.a and Code:libm.so, probably the same complains related to libc. Once more, solved them with more sym links.
Finally, I was able to create it with Code:CPPFLAGS=-m32 CFLAGS=-m32 LDFLAGS=-m32 ./configure --prefix=/media/34GB/Arquivos-de-Programas-Linux/Alsa-1.0.17-32/ --host=i386-linux-gnuHowever, obviously, something was missing. Perhaps the loader had to be the one of the 32bit libc? What else can be?
As soon as the building and installing processes were done, I notice that the install folder size of was much smaller than the 64bi version (1.6mb against 4.7mb). So something went wrong. Investigating al ittle more, I executed ldd on ibasound.so. And the result? Code:not a dynamic executableObviously it should show something like the 64bit version shows:
Code:linux-vdso.so.1 => (0x00007fffc03ff000)
libm.so.6 => /lib/libm.so.6 (0x00007fd779958000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fd779754000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fd779536000)
librt.so.1 => /lib/librt.so.1 (0x00007fd77932e000)
libc.so.6 => /lib/libc.so.6 (0x00007fd778fab000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd779ed1000)The overall reason behind this weird behavior is also quite obvious> I am adding 32bit from the scratch to my system, piece by piece. First I compiled a gcc with 32bit support, installed it in some non default dir, removed the old gcc and then created symbolic links to the new on Code:/usr/local/binAfter that, I created a dir called /usr/lib32 and then I created a sym link to the 32bit version of libstdc++ on it.
More or less about the same time, I also compiled and installed in a non default dir, a 32bit version of glibc
Then I finally went to compile a 32bit version of alsa. First, configure complained about incompatible version of libc.a and libc.so. I then created symbolic links to the 32bit version of them on Code:/usr/lib32. It then complained about some files: Code:crt1.0 crti.o crtn.o I did the same for them. Finally, it complained about Code:libm.a and Code:libm.so, probably the same complains related to libc. Once more, solved them with more sym links.
Finally, I was able to create it with Code:CPPFLAGS=-m32 CFLAGS=-m32 LDFLAGS=-m32 ./configure --prefix=/media/34GB/Arquivos-de-Programas-Linux/Alsa-1.0.17-32/ --host=i386-linux-gnuHowever, obviously, something was missing. Perhaps the loader had to be the one of the 32bit libc? What else can be?