Mailing List Archive

On 19 Jan 2016 13:47, Alex McWhirter wrote:
> In many places im seeing LD output this in the configure script of a
> multilib glibc ebuild. This is configuring 32bit glibc on a 64bit host.
>
> sparc:v9 architecture of input file `somefile' is incompatible with
> sparc output
>
> So it looks like LD is working right, but GCC is still compiling 64bit.
> Or it could be G++ compiling 64bit as i don't see a -m32 flag set for
> it? I seem some references to G++.

i'm guessing the multilib toolchain setup isn't working correctly.
can you attach the full log ?

what should be happening:
- profile declares CFLAGS_sparc32 and friends for correct ABI settings
- profile declares the active list of ABIs
- `portageq envvar MULTILIB_ABIS` should return "sparc64 sparc32"
- glibc ebuild uses multilib.eclass to set up the toolchain
- uses profile env var settings
- see multilib_toolchain_setup and multilib_env
- ebuild log the exact settings used before configure to check
- those settings are passed down to configure invocation

wrt g++, we might not be setting up CXXFLAGS in the glibc ebuild as this
hasn't historically come up.
-mike

On 01/19/2016 01:47 PM, Alex McWhirter wrote:
> In many places im seeing LD output this in the configure script of a
> multilib glibc ebuild. This is configuring 32bit glibc on a 64bit host.
>
> sparc:v9 architecture of input file `somefile' is incompatible with
> sparc output
>
>
>
> So it looks like LD is working right, but GCC is still compiling 64bit.
> Or it could be G++ compiling 64bit as i don't see a -m32 flag set for
> it? I seem some references to G++.
>

I found the issue here, but i'm not sure how to handle it. The logic in
common.eblit is wrong for sparc64. See below

<snip>
local cpu
case ${CTARGET} in
sparc64-*)
case $(get-flag mcpu) in
niagara[234])
if version_is_at_least 2.8 ; then
cpu="sparc64v2"
elif version_is_at_least 2.4 ; then
cpu="sparc64v"
elif version_is_at_least 2.2.3 ;
then
cpu="sparc64b"
fi
;;
niagara)
if version_is_at_least 2.4 ; then
cpu="sparc64v"
elif version_is_at_least 2.2.3 ;
then
cpu="sparc64b"
fi
;;
ultrasparc3)
cpu="sparc64b"
;;
*)
# We need to force at least v9a
because the base build doesn't
# work with just v9.
#
https://sourceware.org/bugzilla/show_bug.cgi?id=19477
[[ -z ${cpu} ]] && append-flags
"-Wa,-xarch=v9a"
;;
esac
;;
</snip>

Pulling from CHOST and basing CTARGET off of that is probably not the
best idea for sparc64 because the result will always be 64 bit. Hence
why we have build errors when attempting 32bit multi lib.

Also, mcpu=ultrasparc will set the target to v9a and all sparv9 boxes
are backwards compatible to v9a. Ultrasparc being the lowest common
denominator for 64 bit means we can clean up the wild card a bit. That's
not a big deal really, forcing v9a should have a similar effect.

I need to research the specific targets a bit and maybe i can come up
with an answer. Do we have {$ABI} here?

On 19 Jan 2016 14:16, Alex McWhirter wrote:
> I found the issue here, but i'm not sure how to handle it. The logic in
> common.eblit is wrong for sparc64. See below
>
> <snip>
> local cpu
> case ${CTARGET} in
> sparc64-*)
> case $(get-flag mcpu) in
> niagara[234])
> if version_is_at_least 2.8 ; then
> cpu="sparc64v2"
> elif version_is_at_least 2.4 ; then
> cpu="sparc64v"
> elif version_is_at_least 2.2.3 ;
> then
> cpu="sparc64b"
> fi
> ;;
> niagara)
> if version_is_at_least 2.4 ; then
> cpu="sparc64v"
> elif version_is_at_least 2.2.3 ;
> then
> cpu="sparc64b"
> fi
> ;;
> ultrasparc3)
> cpu="sparc64b"
> ;;
> *)
> # We need to force at least v9a
> because the base build doesn't
> # work with just v9.
> #
> https://sourceware.org/bugzilla/show_bug.cgi?id=19477
> [[ -z ${cpu} ]] && append-flags
> "-Wa,-xarch=v9a"
> ;;
> esac
> ;;
> </snip>
>
> Pulling from CHOST and basing CTARGET off of that is probably not the
> best idea for sparc64 because the result will always be 64 bit. Hence
> why we have build errors when attempting 32bit multi lib.

i don't think that's the case. if you look up a level:
- setup_target_flags is only called by setup_flags
- setup_flags is only called by setup_env
- setup_env first calls multilib_env

so multilib_env should have set up the state such that CTARGET reflects
the current ABI (e.g. a sparc-* tuple) rather than the native one (e.g.
always sparc64-*).

> Also, mcpu=ultrasparc will set the target to v9a and all sparv9 boxes
> are backwards compatible to v9a. Ultrasparc being the lowest common
> denominator for 64 bit means we can clean up the wild card a bit. That's
> not a big deal really, forcing v9a should have a similar effect.

the reason that append is there is to workaround (imo) a build bug rather
than something we really want to be doing. if we did it all the time, it
would clobber existing flags someone might have set.

> I need to research the specific targets a bit and maybe i can come up
> with an answer. Do we have {$ABI} here?

we have $ABI, but it should have already been selected (see my call
graph above)

-mike

On 01/19/2016 02:38 PM, Mike Frysinger wrote:
> On 19 Jan 2016 14:16, Alex McWhirter wrote:
>> I found the issue here, but i'm not sure how to handle it. The logic in
>> common.eblit is wrong for sparc64. See below
>>
>> <snip>
>> local cpu
>> case ${CTARGET} in
>> sparc64-*)
>> case $(get-flag mcpu) in
>> niagara[234])
>> if version_is_at_least 2.8 ; then
>> cpu="sparc64v2"
>> elif version_is_at_least 2.4 ; then
>> cpu="sparc64v"
>> elif version_is_at_least 2.2.3 ;
>> then
>> cpu="sparc64b"
>> fi
>> ;;
>> niagara)
>> if version_is_at_least 2.4 ; then
>> cpu="sparc64v"
>> elif version_is_at_least 2.2.3 ;
>> then
>> cpu="sparc64b"
>> fi
>> ;;
>> ultrasparc3)
>> cpu="sparc64b"
>> ;;
>> *)
>> # We need to force at least v9a
>> because the base build doesn't
>> # work with just v9.
>> #
>> https://sourceware.org/bugzilla/show_bug.cgi?id=19477
>> [[ -z ${cpu} ]] && append-flags
>> "-Wa,-xarch=v9a"
>> ;;
>> esac
>> ;;
>> </snip>
>>
>> Pulling from CHOST and basing CTARGET off of that is probably not the
>> best idea for sparc64 because the result will always be 64 bit. Hence
>> why we have build errors when attempting 32bit multi lib.
> i don't think that's the case. if you look up a level:
> - setup_target_flags is only called by setup_flags
> - setup_flags is only called by setup_env
> - setup_env first calls multilib_env
>
> so multilib_env should have set up the state such that CTARGET reflects
> the current ABI (e.g. a sparc-* tuple) rather than the native one (e.g.
> always sparc64-*).
>
>> Also, mcpu=ultrasparc will set the target to v9a and all sparv9 boxes
>> are backwards compatible to v9a. Ultrasparc being the lowest common
>> denominator for 64 bit means we can clean up the wild card a bit. That's
>> not a big deal really, forcing v9a should have a similar effect.
> the reason that append is there is to workaround (imo) a build bug rather
> than something we really want to be doing. if we did it all the time, it
> would clobber existing flags someone might have set.
>
>> I need to research the specific targets a bit and maybe i can come up
>> with an answer. Do we have {$ABI} here?
> we have $ABI, but it should have already been selected (see my call
> graph above)
>
> -mike

Perhaps we have a bug somewhere else then?

The output below is from a GLIBC build

* Configuring glibc for nptl
* ABI: sparc32
* CBUILD: sparc64-unknown-linux-gnu
* CHOST: sparc64-unknown-linux-gnu
* CTARGET: sparc64-unknown-linux-gnu
* CBUILD_OPT: sparc64-unknown-linux-gnu
* CTARGET_OPT: sparc64-unknown-linux-gnu
* CC: sparc64-unknown-linux-gnu-gcc -m32
* LD:
* ASFLAGS:
* CFLAGS: -mcpu=ultrasparc -pipe -fcall-used-g6 -O2
-fno-strict-aliasing
* CPPFLAGS:
* CXXFLAGS: -mcpu=ultrasparc -pipe -fcall-used-g6 -O2
-fno-strict-aliasing
* LDFLAGS: -Wl,-O1 -Wl,--as-needed
* Manual CC: sparc64-unknown-linux-gnu-gcc -m32 -Wl,-O1
-Wl,--as-needed


multilib_env is pulling the in ABI correctly, but not CTARGET. Unless we
should be setting CTARGET_$ABI in the profile?

I have the CHOST's below in the profile now.

CHOST_sparc32="sparc-unknown-linux-gnu"
CHOST_sparc64="sparc64-unknown-linux-gnu"

On 19 Jan 2016 14:44, Alex McWhirter wrote:
> On 01/19/2016 02:38 PM, Mike Frysinger wrote:
> > On 19 Jan 2016 14:16, Alex McWhirter wrote:
> >> I found the issue here, but i'm not sure how to handle it. The logic in
> >> common.eblit is wrong for sparc64. See below
> >>
> >> <snip>
> >> local cpu
> >> case ${CTARGET} in
> >> sparc64-*)
> >> </snip>
> >>
> >> Pulling from CHOST and basing CTARGET off of that is probably not the
> >> best idea for sparc64 because the result will always be 64 bit. Hence
> >> why we have build errors when attempting 32bit multi lib.
> >
> > i don't think that's the case. if you look up a level:
> > - setup_target_flags is only called by setup_flags
> > - setup_flags is only called by setup_env
> > - setup_env first calls multilib_env
> >
> > so multilib_env should have set up the state such that CTARGET reflects
> > the current ABI (e.g. a sparc-* tuple) rather than the native one (e.g.
> > always sparc64-*).
> >
> >> Also, mcpu=ultrasparc will set the target to v9a and all sparv9 boxes
> >> are backwards compatible to v9a. Ultrasparc being the lowest common
> >> denominator for 64 bit means we can clean up the wild card a bit. That's
> >> not a big deal really, forcing v9a should have a similar effect.
> >
> > the reason that append is there is to workaround (imo) a build bug rather
> > than something we really want to be doing. if we did it all the time, it
> > would clobber existing flags someone might have set.
> >
> >> I need to research the specific targets a bit and maybe i can come up
> >> with an answer. Do we have {$ABI} here?
> >
> > we have $ABI, but it should have already been selected (see my call
> > graph above)
> >
> > -mike
>
> Perhaps we have a bug somewhere else then?
>
> The output below is from a GLIBC build
>
> * Configuring glibc for nptl
> * ABI: sparc32
> * CBUILD: sparc64-unknown-linux-gnu
> * CHOST: sparc64-unknown-linux-gnu
> * CTARGET: sparc64-unknown-linux-gnu
> * CBUILD_OPT: sparc64-unknown-linux-gnu
> * CTARGET_OPT: sparc64-unknown-linux-gnu
> * CC: sparc64-unknown-linux-gnu-gcc -m32
> * LD:
> * ASFLAGS:
> * CFLAGS: -mcpu=ultrasparc -pipe -fcall-used-g6 -O2
> -fno-strict-aliasing
> * CPPFLAGS:
> * CXXFLAGS: -mcpu=ultrasparc -pipe -fcall-used-g6 -O2
> -fno-strict-aliasing
> * LDFLAGS: -Wl,-O1 -Wl,--as-needed
> * Manual CC: sparc64-unknown-linux-gnu-gcc -m32 -Wl,-O1
> -Wl,--as-needed
>
>
> multilib_env is pulling the in ABI correctly, but not CTARGET. Unless we
> should be setting CTARGET_$ABI in the profile?
>
> I have the CHOST's below in the profile now.
>
> CHOST_sparc32="sparc-unknown-linux-gnu"
> CHOST_sparc64="sparc64-unknown-linux-gnu"

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

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

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

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.

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.

On 20 Jan 2016 02:40, Alex McWhirter wrote:
> 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.

since you have 32-bit & 64-bit builds of sparc already, just copy by hand
the 32-bit gcc libs in to the right place. then build glibc, and then
rebuild gcc. you should be able to bootstrap multilib build that way.
-mike

On 01/20/2016 02:01 PM, Mike Frysinger wrote:
> On 20 Jan 2016 02:40, Alex McWhirter wrote:
>> 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.
> since you have 32-bit & 64-bit builds of sparc already, just copy by hand
> the 32-bit gcc libs in to the right place. then build glibc, and then
> rebuild gcc. you should be able to bootstrap multilib build that way.
> -mike

Yea, i tried that. But on 32bit, /lib is a symlink to /lib32 and on
64bit it's a symlink to /lib64. libraries on sparc32 look in /lib for
other 32bit libraries and sparc64 does the same for 64bit libraries. So
when 32 bit gcc expects to find 32bit in /lib you end up with the same
problem.

Im playing around with crossdev atm, need to find a way to pass v9a arch
when chost is X86...

On 20 Jan 2016 15:49, Alex McWhirter wrote:
> On 01/20/2016 02:01 PM, Mike Frysinger wrote:
> > On 20 Jan 2016 02:40, Alex McWhirter wrote:
> >> 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.
> > since you have 32-bit & 64-bit builds of sparc already, just copy by hand
> > the 32-bit gcc libs in to the right place. then build glibc, and then
> > rebuild gcc. you should be able to bootstrap multilib build that way.
>
> Yea, i tried that. But on 32bit, /lib is a symlink to /lib32 and on
> 64bit it's a symlink to /lib64. libraries on sparc32 look in /lib for
> other 32bit libraries and sparc64 does the same for 64bit libraries. So
> when 32 bit gcc expects to find 32bit in /lib you end up with the same
> problem.

since sparc64 & multilib is new work, let's get it right from the start:
you should not be using SYMLINK_LIB=yes at all. so we'll add this line
to arch/sparc/make.defaults:
SYMLINK_LIB=no
-mike

On 01/20/2016 04:51 PM, Mike Frysinger wrote:
> On 20 Jan 2016 15:49, Alex McWhirter wrote:
>> On 01/20/2016 02:01 PM, Mike Frysinger wrote:
>>> On 20 Jan 2016 02:40, Alex McWhirter wrote:
>>>> 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.
>>> since you have 32-bit & 64-bit builds of sparc already, just copy by hand
>>> the 32-bit gcc libs in to the right place. then build glibc, and then
>>> rebuild gcc. you should be able to bootstrap multilib build that way.
>> Yea, i tried that. But on 32bit, /lib is a symlink to /lib32 and on
>> 64bit it's a symlink to /lib64. libraries on sparc32 look in /lib for
>> other 32bit libraries and sparc64 does the same for 64bit libraries. So
>> when 32 bit gcc expects to find 32bit in /lib you end up with the same
>> problem.
> since sparc64 & multilib is new work, let's get it right from the start:
> you should not be using SYMLINK_LIB=yes at all. so we'll add this line
> to arch/sparc/make.defaults:
> SYMLINK_LIB=no
> -mike

I was more or less emulating the amd64 profile, so i figure that was the
right way to go. Is there anything else i should be looking for? I
carried this over from the old sparc profile for sparc32.

FEATURES="-multilib-strict"
MULTILIB_STRICT_DIRS="/lib32 /usr/lib32 /usr/kde/*/lib32 /usr/qt/*/lib32
/usr/X11R6/lib32"

That's seems somewhat dirty to me, but i carried it over because it worked.

This is probably slightly off topic, but my next order of business after
getting multilib finished will be writing a wiki / other docs on
crossdev. In short i am absolutely blow away with how easy it makes
cross compiling.

However i spent about 3 hours frustrated with it because i didn't
realize that it create a whole new environment in /usr/(CHOST)... So i
proceeded to create my own env and try to override all of the env vars
portage was making. The using qemu to emulate sparc64 binaries so i
could pass config checks.

Until i found (CHOST)-emerge that is, and subsequently realized it had
it's own env...

On 21 Jan 2016 01:28, Alex McWhirter wrote:
> On 01/20/2016 04:51 PM, Mike Frysinger wrote:
> > On 20 Jan 2016 15:49, Alex McWhirter wrote:
> >> Yea, i tried that. But on 32bit, /lib is a symlink to /lib32 and on
> >> 64bit it's a symlink to /lib64. libraries on sparc32 look in /lib for
> >> other 32bit libraries and sparc64 does the same for 64bit libraries. So
> >> when 32 bit gcc expects to find 32bit in /lib you end up with the same
> >> problem.
> >
> > since sparc64 & multilib is new work, let's get it right from the start:
> > you should not be using SYMLINK_LIB=yes at all. so we'll add this line
> > to arch/sparc/make.defaults:
> > SYMLINK_LIB=no
>
> I was more or less emulating the amd64 profile, so i figure that was the
> right way to go. Is there anything else i should be looking for? I
> carried this over from the old sparc profile for sparc32.
>
> FEATURES="-multilib-strict"
> MULTILIB_STRICT_DIRS="/lib32 /usr/lib32 /usr/kde/*/lib32 /usr/qt/*/lib32
> /usr/X11R6/lib32"
>
> That's seems somewhat dirty to me, but i carried it over because it worked.

we should delete that and figure out what needs adjusting otherwise
-mike

On 21 Jan 2016 05:18, Alex McWhirter wrote:
> This is probably slightly off topic, but my next order of business after
> getting multilib finished will be writing a wiki / other docs on
> crossdev. In short i am absolutely blow away with how easy it makes
> cross compiling.
>
> However i spent about 3 hours frustrated with it because i didn't
> realize that it create a whole new environment in /usr/(CHOST)... So i
> proceeded to create my own env and try to override all of the env vars
> portage was making. The using qemu to emulate sparc64 binaries so i
> could pass config checks.
>
> Until i found (CHOST)-emerge that is, and subsequently realized it had
> it's own env...

there's an embedded handbook, but it's waiting on migration to the wiki:
https://bugs.gentoo.org/show_bug.cgi?id=553112
-mike