On 2016-09-09 00:17, Michał Górny wrote:
On Thu, 08 Sep 2016 18:49:06 -0400
alexmcwhir...@triadic.us wrote:
I'm in the process of rebuilding a new livecd via catalyst with this
commit reverted just to be sure this is the issue, but this is the
only
libc commit since my last build. It usually takes about 48 hours for a
full stage1 - livecd build so i wont know for sure until then.
commit: ffc59b9e2bbe9ad89a1ab60e3a147785fe944141
Do not call multilib_env_reset unless cross-compiling, in order to
prevent the function from redefining profile-defined variables such as
LIBDIR_*.
boost is failing as follows.
/bin/sh: error while loading shared libraries: libc.so.6: failed to
map
segment from shared object
gcc.compile.c++
bin.v2/libs/math/build/gcc-4.9/gentoorelease/boost.locale.icu-off/pch-off/threading-multi/comp_ellint_1f.o
In file included from ./boost/format.hpp:50:0,
from ./boost/math/policies/error_handling.hpp:31,
from
./boost/math/special_functions/ellint_rf.hpp:22,
from ./boost/math/special_functions/ellint_1.hpp:22,
from
libs/math/build/../src/tr1/comp_ellint_1f.cpp:11:
./boost/format/parsing.hpp:1:0: internal compiler error: Aborted
//
----------------------------------------------------------------------------
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
It's worth noting that this is a custom profile based on the amd64
profile for sparc64. That being said, it has been rock solid since
January, this is the first issue that i have come across of this
nature.
If you use a custom profile, you need to ensure that it sets all
the standard variables and not rely on random ebuilds overriding them
for you. Your 'rock solid' argument doesn't mean anything to me; you
just didn't notice it being broken, that's all.
I've took a quick look and don't see anything obviously wrong. But
then, I have no clue which of those profiles you actually use and how.
If you want to debug it, I suggest dumping all the variables set by
multilib_env() in the place patch changes the eclass, and seeing which
one is different.
Will do, i'm very much willing to accept that my profiles are broken as
they are currently a WIP. Ideally this is something that should likely
be fixed in the profiles anyways. I just wanted to put this out there in
case there were any obvious reasons as to the cause. I'll do some
digging, and report back if i find anything else strange. glibc on
sparc64 has never particularly been a walk in the park.
