Re: [gentoo-sparc] GLIBC Issues

[Alex McWhirter]

On 01/19/2016 04:05 PM, Mike Frysinger wrote:
> if you delete that CHOST override, do the *_OPT values end up being
> sparc-* ? if not, put `set -x` at the top of setup_env and `set +x` at
> the bottom of setup_env and send that log over. sparc is the only one
> that sets CTARGET_OPT in this sub-case, so there might be a bug in
> there. unfortunately we can't get away from overriding the tuple for
> glibc since user's can't really change it and glibc itself does no
> probing :(. my preference otherwise would be to delete this block of
> code entirely. -mike

No it doesn't seem to make any difference. multilib_env doesn't set
CTARGET or CHOST, it just sets the _$ABI variants. It seems to be a
backup in case they aren't set in the profile.

In my profile ABI and DEFAULT_ABI are set to sparc64 and glibc changes
that to sparc32 when building multilib which is correct. The question i
have is, where is CTARGET set? glibc's ebuild doesn't seem to do it and
my profile doesn't either. multlib_env only sets CTARGET_$ABI which
isn't use here.

For what it's worth glibc will probe for which assembly to use based on
the value of -mpcu. I've built enough LFS builds on sparc to know what
happens when you pass glibc -mpcu=v9 and it need something more
specific. But if you use -mcpu=ultrasparc,ultrasparc3,etc... glibc will
pick the right assembly on it's own. At least the current version does
anyways. So getting rid of *_OPT vars should be fine as long as people
are something more specific than -mcpu=v9