32Bit dynamic library is actually static

coltson · 07-01-2021, 08:31 PM

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 executable

Obviously 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/bin

After 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-gnu

However, obviously, something was missing. Perhaps the loader had to be the one of the 32bit libc? What else can be?

ordealbyfire83 · 07-01-2021, 09:41 PM

So if I understand right, you built a cross-compiler and used that to compile alsa? What if you use the cross compiler to build a native 32-bit gcc, and then use that to build whatever you're trying to build?

Otherwise, when you cross-compile, you really need to watch the --build --host --target options. Also, a lot of configure scripts use the output of uname to detect your architecture. You might have to temporarily spoof uname to say something else.