On 2016-09-09 00:17, Michał Górny wrote:
> I suggest dumping all the variables set by
> multilib_env() in the place patch changes the eclass, and seeing which
> one is different.
I just did a quick test as suggested, quite a bit of these vars are now
undefined which points the problem. Easy fix, but i wanted to note that
most of the profile code for this was pulled right from the official
sparc32 profile base. I highly suspect glibc on those profiles will
break now, granted there is a lot of outdated / broken things in those
profiles. As far as i know, i am the only person working on updated
sparc32 profiles let alone sparc64 support.
I'm more or less just documenting this for myself at the moment, in case
anyone were to ask about it later on the sparc list. At some point i
will have to look at getting my work pushed upstream, but i wouldn't say
i'm at that point yet.
I'll spin up an install using the old profiles and see if i can verify
this, and open a bug report against sparc if i can verify it.
> I suggest dumping all the variables set by
> multilib_env() in the place patch changes the eclass, and seeing which
> one is different.
I just did a quick test as suggested, quite a bit of these vars are now
undefined which points the problem. Easy fix, but i wanted to note that
most of the profile code for this was pulled right from the official
sparc32 profile base. I highly suspect glibc on those profiles will
break now, granted there is a lot of outdated / broken things in those
profiles. As far as i know, i am the only person working on updated
sparc32 profiles let alone sparc64 support.
I'm more or less just documenting this for myself at the moment, in case
anyone were to ask about it later on the sparc list. At some point i
will have to look at getting my work pushed upstream, but i wouldn't say
i'm at that point yet.
I'll spin up an install using the old profiles and see if i can verify
this, and open a bug report against sparc if i can verify it.