Created attachment 363030 [details, diff] patch to ebuild The attached patch very carefully only builds the libraries for non-native ABIs, even though it does enable certain things in ./configure that are not libraries (to reduce the number of changes from the current version). It also introduces a few functions that may be more useful in multilib-build.eclass.
(In reply to Jonathan Callen from comment #0) > It also introduces a few functions that may be more useful in > multilib-build.eclass. Featurism. Why can't you just put the additional configure switches in a variable? This would be clearer than having two extra functions to care about.
Created attachment 363608 [details, diff] patch to ebuild This version simply uses a variable to store the differences in the ./configure arguments between native and non-native ABIs (properly: the differences between building binaries and building just the libraries).
Created attachment 363818 [details, diff] patch to ebuild Missed one variable that should be set differently for non-native ABIs.
Comment on attachment 363818 [details, diff] patch to ebuild >-src_configure() { >+multilib_src_configure() { >+ local CPPFLAGS=${CPPFLAGS} ac_cv_func_fallocate opts declaring ac_cv_func_fallocate as local doesn't make much sense when you explicitly export it in both code paths below use "myconf" rather than "opts" >+ if multilib_build_binaries; then >+ export ac_cv_header_security_pam_misc_h=$(usex pam) #485486 >... >+ --with-ncurses=$(usex ncurses $(usex unicode auto yes) no) >... >+ $(use_with python) >... >+ $(use_with slang) >+ $(use_with udev) for general library flags, keep those in the common code path. i don't want to have to keep track of what impacts just utils vs utils+libs. >+multilib_src_install() { >+ if multilib_build_binaries; then >+ emake DESTDIR="${D}" install >+ use python && python_optimize >+ else >+ emake DESTDIR="${D}" install-usrlib_execLTLIBRARIES \ >+ install-pkgconfigDATA install-uuidincHEADERS \ >+ install-nodist_blkidincHEADERS install-nodist_mountincHEADERS >+ fi is the overhead of using `emake install` for both that great ? doesn't seem like it, so just have both do the first code path.
For at least some (I don't remember which) of the library flags in question, --enable-foo or --with-foo would require multilib foo in DEPEND, even though nothing that gets built/installed actually *uses* it; also, the long `emake .. install*` for non-native is to ensure that extra things (that might need some of those deps) don't even get built.
i've raised the topic on the util-linux mailing list. they'll see what they can do in terms of making it sane.
(In reply to SpanKY from comment #6) > i've raised the topic on the util-linux mailing list. they'll see what they > can do in terms of making it sane. Any news here? I can't find the thread.
I was able to make much simpler ebuild, reusing the new functions and current code. Most importantly, I didn't disable the configure flags for most of the tools since they don't introduce any deps and aren't build since we hand-pick make targets. +*util-linux-2.24.1-r3 (02 May 2014) + + 02 May 2014; Michał Górny <mgorny@gentoo.org> +util-linux-2.24.1-r3.ebuild: + Introduce multilib support, bug #490968. Committed p.masked. We're in no hurry to unmask it, so the ebuild is still open to changes.
