Created attachment 279697 [details, diff] cflags-1.4.patch With certain older versions of libtool, the following behavior can be seen as will be attached in a build.log or so: /bin/sh /var/tmp/portage/app-text/openjade-1.3.2-r3/work/openjade-1.3.2/libtool --mode=link x86_64-pc-linux-gnu-gcc -Wl,--as-needed -Wl,-O1 -Wl,-t -Wl,--enable-new-dtags -Wl,--hash-style=gnu -m32 -o libogrove.la Node.lo LocNode.lo \ -rpath /usr/lib32 -version-info 0:1:0 -lm -lstdc++ gets translated into: x86_64-pc-linux-gnu-gcc -shared Node.lo LocNode.lo -Wl,--as-needed -lm -lstdc++ -Wl,-O1 -Wl,-t -Wl,--enable-new-dtags -Wl,--hash-style=gnu -Wl,-soname -Wl,libogrove.so.0 -o .libs/libogrove.so.0.0.1 There is a missing -m32 in that linking command, which causes a compilation failure on portage-multilib when the patch from bug 351384 is applied to gcc-config. This is fixed in newer libtools (such as 2.2) and I have attached a patch backporting the fix to libtool-1.4, which is the version of libtool shipped with openjade which calls elibtoolize. I'm not sure of the right patch naming conventions or that much about how ELT-patches stuff works, though. I found if I plopped this into ELT-patches/portage-multilib and added portage-multilib to libtool.eclass, it got magically aplied for openjade :-).
Created attachment 279699 [details] openjade-1.3.2-r3-20110711-build.log