Re: [gentoo-sparc] GLIBC Issues

[Alex McWhirter]

On 01/19/2016 05:18 PM, Mike Frysinger wrote:
> On 19 Jan 2016 16:23, Alex McWhirter wrote:
>> 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.
> CTARGET is set to CHOST by default by glibc itself.  we might only be
> doing that at a higher level though, so we might have to reset it in
> there.
>
>> 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
> i'm like 99% sure you're not looking at the right thing :).  the issue
> isn't multiarch/ifunc (which works), or for some feature testing (which
> works), or for code generation by gcc itself (which works), but for
> selection of subdirs which host different files.  example:
>
> $ ../configure CC=sparc-unknown-linux-gnu-gcc \
> 	CFLAGS='-O2 -mcpu=niagara -pipe' \
> 	--prefix=/usr --host=sparcv9v-unknown-linux-gnu
> $ grep ^config-sysdirs config.make
> config-sysdirs =  sysdeps/unix/sysv/linux/sparc/sparc32/sparcv9/fpu/multiarch sysdeps/sparc/sparc32/sparcv9/fpu/multiarch sysdeps/sparc/sparc32/sparcv9/fpu sysdeps/sparc/sparc32/fpu sysdeps/unix/sysv/linux/sparc/sparc32/sparcv9/fpu sysdeps/unix/sysv/linux/sparc/sparc32/sparcv9 sysdeps/unix/sysv/linux/sparc/sparc32/fpu sysdeps/unix/sysv/linux/sparc/sparc32 sysdeps/ieee754/ldbl-64-128 sysdeps/ieee754/ldbl-opt sysdeps/unix/sysv/linux/sparc sysdeps/sparc/nptl sysdeps/unix/sysv/linux sysdeps/nptl sysdeps/pthread sysdeps/gnu sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix sysdeps/posix sysdeps/sparc/sparc32/sparcv9/multiarch sysdeps/sparc/sparc32/sparcv9 sysdeps/sparc/sparc32 sysdeps/wordsize-32 sysdeps/ieee754/ldbl-128 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/sparc/sparc32/soft-fp sysdeps/sparc/fpu sysdeps/sparc sysdeps/ieee754 sysdeps/generic
>
> $ ../configure CC=sparc-unknown-linux-gnu-gcc \
> 	CFLAGS='-O2 -mcpu=niagara -pipe' \
> 	--prefix=/usr --host=sparc-unknown-linux-gnu
> $ grep ^config-sysdirs config.make
> config-sysdirs =  sysdeps/unix/sysv/linux/sparc/sparc32/fpu sysdeps/sparc/sparc32/fpu sysdeps/unix/sysv/linux/sparc/sparc32 sysdeps/ieee754/ldbl-64-128 sysdeps/ieee754/ldbl-opt sysdeps/unix/sysv/linux/sparc sysdeps/sparc/nptl sysdeps/unix/sysv/linux sysdeps/nptl sysdeps/pthread sysdeps/gnu sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix sysdeps/posix sysdeps/sparc/sparc32 sysdeps/wordsize-32 sysdeps/ieee754/ldbl-128 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/sparc/sparc32/soft-fp sysdeps/sparc/fpu sysdeps/sparc sysdeps/ieee754 sysdeps/generic
>
> see how there is significant difference here ?
> -mike

Oh... yea that is a very significant difference. It seems incredibly
ulgy that glibc can't work this out on it's own. I wondering if we're
missing a check here. It seems to work fine on sparc with a 64bit
multilib env, but not sparc64 with a 32bit multilib env.