Re: [gentoo-sparc] GLIBC Issues

[Alex McWhirter]

On 01/19/2016 10:15 PM, Alex McWhirter wrote:
> 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.
>

So 32bit libc is going to need a 32bit gcc, gcc is capable of -m32 but
it's libs are ELF 64 only. So we need to compile gcc with multilib as well.

gcc depends on libc, so we have a chicken and egg problem here. I am
trying to pass --without-headers and --with-newlib to gcc, but it still
looks for stubs-32.h which isn't there.

Trying now with --disable-shared but i don't see how that will make a
difference.