Calls to econf() without specifying --libdir result in inconsistent behavior between arches that specify LIBDIR_${ABI} (e.g. amd64) and those that do not (e.g. x86). Specifically, if a package defaults to installing in /$(get_libdir), one must specify "--libdir=/$(get_libdir)", otherwise the contents get installed in /usr/$(get_libdir) on amd64 and /$(get_libdir) on x86. Thus far, I have been able to come up with three options, none of which seem palatable: 1. Stop passing --libdir automatically: breaks non-multilib-aware packages 2. Add LIBDIR_x86="lib" (or LIBDIR_default="lib") for x86 profiles: forces packages currently installing to /$(get_libdir) to specify --libdir 3. Default CONF_PREFIX to "/" instead of "/usr": pollutes /$(get_libdir) This has been in portage since at least 2.0.x, and possibly earlier; bug, meet feature.
Could you point to a specific package? Looking at the PMS, econf respects '--prefix' here (not sure why not --exec-prefix as well...). I'd say that should be 'good enough' to solve this -- request the packages that install to / specify --prefix explicitly.
Let me check, it's demonstrably been years since I poked at this. I do know this was from when I was packaging things myself and had discussed this with someone on #g-portage who asked me to submit this bug.
Thanks to Anthony for finding these bugs, saves me having to spin back up and figure out where I had been (and what machine I was working on) 5 years ago.
This is Algorithm 9 in PMS: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-135002r9 I don't see why it would be inconsistent. If the ABI variable is set, then --libdir=${prefix}/${libdir} is passed to configure. ${prefix} is equal to ${EPREFIX}/usr unless the caller overrides it with --prefix. If ABI is not set, then libdir should be the default, which according to GNU coding standards is $(exec_prefix)/lib. If the package uses something different then it should be fixed upstream.
No progress. Closing.
