submitting two new ebuilds for getting blas-atlas working under portage-multilib which should also continue working under regular portage. the problem was from multiple sources, first, gentoo-multilib pre-determines that your fortran compiler is gfortran, and this breaks calls to the fortran eclass since it insists that you should be calling strictly "gfortran" and not any particular version of it. if a user lacks gfortran, the compile errors should be pretty explicit enough on why the build fails anyways. second, the BLD_DIR and RPATH definitions occurred outside of any of the stages, which is not abi-wrapped, and therefore fails to be properly defined for whichever abi is built second. third, the archselect variable only checked for amd64, or ppc64 architecture and then proceeded to set -b 64, on amd64 this did fail, and would most likely also fail on ppc64 and sparc. this is because when under the x86/ppc/sparc32 abi's, we need to pass -b 32, while on the amd64/ppc64/sparc64 abi's, we need to pass -b 64.
Created attachment 237193 [details] fixed ebuild for 3.8.0
Created attachment 237195 [details] fixed ebuild for 3.9.23
Thank you for your work on this! Though I would like to ask you to submit diff against original ebuild rather than whole files, next time. Best regards, Kacper Kowalik
Found out that lapack-atlas exhibits similar behavior for similar reasons, exclusion being that the fortran eclass seems to behave itself... I notice it's not called directly either... something must be calling it and that something behaves itself I guess? Too lazy to look into something that already works ;) Anyways, patches for lapack will follow soon.
Created attachment 237215 [details, diff] patch to fix lapack ebuild for 3.8.0
Created attachment 237217 [details, diff] patch to fix lapack ebuild for 3.9.23
Dropped all atlas packages from tree. Please use sci-libs/atlas from sci overlay. If problem still exist with that package, please reopen the bug or file a new one.