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