Re: [gentoo-dev] recent glibc commit breaks boost on sparc64

[Michał Górny]

On Thu, 08 Sep 2016 18:49:06 -0400
alexmcwhirter@×××××××.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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>