when using e.g. MULTILIB_ABIS="amd64 x86" DEFAULT_ABI="x86" all attempts to compile modules will fail since they get built 32bit instead of 64bit, which of course is not what we want.
Created attachment 77098 [details, diff] suggested patch
mips herd: i'm not absolutely sure if the logic in the patch is correct, could you check it out please? :)
someone from the mips herd told me that the patch should be correct, but that they don't use multilib anyway
Comment on attachment 77098 [details, diff] suggested patch actually, let me revise this patch. there has recently been a change in toolchain-funcs.eclass which invalidates this patch for ppc{,64}
I think the sanest solution to this problem would be just setting ABI=$(get_kernel_abi) in linux-mod.eclass and handling the rest either in the profiles by setting KERNEL_ABI=... or in multilib.eclass with something like this: +# get_kernel_abi() +# Return the ABI used by the kernel and modules +get_kernel_abi() { + if has_multilib_profile ; then + case $(get_abi_var CHOST) in + *86*) echo "amd64";; + mips*) echo "n64";; + powerpc*) echo "ppc64";; + sparc*) echo "sparc64";; + *) echo "${DEFAULT_ABI}";; + esac + else + echo "${DEFAULT_ABI}" + fi +} + However, I'm much in favour of setting it in the profiles.. eradicator, what's your opinion?
I think the sanest solution to this problem would be just setting ABI=$(get_kernel_abi) in linux-mod.eclass and handling the rest either in the profiles by setting KERNEL_ABI=... or directly with some uname -m magic in multilib.eclass. Personally, I'm in favour of setting it in the profiles.. eradicator, what's your opinion?
bleh, screw comment 5 :P
Created attachment 81057 [details, diff] enable use of KERNEL_ABI
Don't think it's going to be as simple as that. This will affect all packages that inherit linux-mod and it's going to affect everything they compile. For example lirc inherits linux-mod and provides a kernel module, shared libs and executables. The patch as it stands would force all of this to be compiled for the KERNEL_ABI which is not what you want. Moreover it would override anything you set on the command line.
(In reply to comment #9) > Don't think it's going to be as simple as that. This will affect all packages > that inherit linux-mod and it's going to affect everything they compile. For > example lirc inherits linux-mod and provides a kernel module, shared libs and > executables. The patch as it stands would force all of this to be compiled for > the KERNEL_ABI which is not what you want. Moreover it would override anything > you set on the command line. well, that's basically not different from any other eclass. setting ABI=KERNEL_ABI makes sense, since everything else will just break. i tend to claim that the number of packages that compile executables/libraries beside kernel modules is rather low, but that's only a vague feeling. pkg_setup() { ABI2=${ABI} linux-mod_pkg_setup ABI=${ABI2} } should be a valid workaround for those packages. if the number of packages compiling additional stuff is higher than the number of those who don't, there's no point in having the eclass doing the ABI=${KERNEL_ABI} of course, but then we'll have to set it for the rest.. or maybe you know a fix that would approach both types of packages? i unfortunately don't :/
i added KERNEL_ABI to multilib.eclass (not to the kernel eclasses though) adding arches with multilib profiles which might be interested in using it
Created attachment 83078 [details, diff] linux-mod patch This patch only sets ABI for linux-mod_src_compile() which ensures that only kernel modules get built with KERNEL_ABI, the rest of the package will be built with whatever ABI was chosen
patch committed
