dev-libs/lzo-2.04 includes assembly sourcecode files which are built using custom build rules instead of the standard automake build rules. These build rules do not provide any ASFLAGS/CCASFLAGS-like variable to which compilation flags (i.e., -m32) can be passed to the compiler driver. Thus, when trying to compile a 32-bit(x86) version of dev-libs/lzo-2.04 (on a system where gcc-config is patched to ignore the deprecated CFLAGS_${ABI}), the assembly files are compiled as if for the amd64 platform instead of x86 and linking fails. See to-be-attached build.log as well as the to-be-attached patches ;-).
Created attachment 267163 [details] build.log
Created attachment 267165 [details] emerge --info
Created attachment 267167 [details, diff] lzo-2.04-asm-makefile.patch This fixes the issue by killing the explicit make rules for building .S files and preferring automake's build rules. It also invokes AM_PROG_AS, which will set up CCAS and CCASFLAGS, where CCAS=$(CC) and CCASFLAGS=$(CFLAGS) which gets the behavior of the compiler driver being called with $(CFLAGS) which is required for multilib-portage to work.
Created attachment 267169 [details, diff] lzo-2.04.ebuild-asm-makefile.patch The changes necessary to lzo-2.04.ebuild to get the patch working properly. A simple eautoreconf does not work with lzo. I have no idea where lzo gets the mfx_* autoconf macros from, but it certainly does not ship them in m4/ like it should. To fix this, the sed expression grabs all of these macros from aclocal.m4 and stores them into acinclude.m4 (otherwise eautoreconf causes an error; also, eautoreconf is required because the prior patch touches configure.ac and src/Makefile.am).
Patch emailed to upstream, awaiting reply.
Another way to fix this is to fix bug 365407, where upstream fixes this bug in a similar way to the way attachment 267167 [details, diff] fixes it.
Fixed in dev-libs/lzo-2.05 (bug 365407).
