On Wed, 25 Jul 2018 00:34:16 +0100 Sergei Trofimovich <sly...@gentoo.org> wrote:
> On Wed, 25 Jul 2018 00:09:28 +0100
> James Le Cuirot <ch...@gentoo.org> wrote:
>
> > The triplet will change from armv7a-hardfloat-linux-gnueabi to
> > armv7a-unknown-linux-gnueabihf or similar. The function already
> > treated the latter as hardfloat but ambiguous triplets such as
> > arm-unknown-linux-gnueabi will change from hardfloat to softfloat in
> > line with most everyone else. However, we will now check existing
> > toolchains to avoid breaking existing systems, if possible.
>
> [+arm@ CC]
I had intended for most of the information to go into the news item but
I guess this commit message is the best place for additional background
information that may not concern the users so I'll beef it up a bit.
> 1. This changelog is not clear if arm-unknown-linux-gnueabi will
> change meaning in this commit.
Agreed, the wording could be clearer, I will improve it. I was also
partly wrong because although tc-is-softfloat did consider
arm-unknown-linux-gnueabi to be hardfloat, toolchain.eclass applies
the additional armv[67]* condition. The example you gave on IRC was
armv7a-unknown-linux-gnueabi so I will mention that instead.
> 2. Did Gentoo ever use arm-unknown-linux-gnueabi tuple? I don't see
> it in recent profile history.
This was wrong as per above but armv7a-unknown-linux-gnueabi was never
used either. However, crossdev expands arm to arm-unknown-linux-gnueabi.
17.0/musl also defaults to arm-unknown-linux-musleabi. I'm just trying
to cover all the bases. :)
> 3. What are existing toolchain tuples? All the ones people use?
Yes. Who knows what's out there? ;) I'll clarify that
> > ---
> > eclass/toolchain-funcs.eclass | 39 ++++++++++++++++++++++++++++-------
> > 1 file changed, 32 insertions(+), 7 deletions(-)
> >
> > diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> > index cea8949b45d7..f484fffc2664 100644
> > --- a/eclass/toolchain-funcs.eclass
> > +++ b/eclass/toolchain-funcs.eclass
> > @@ -204,13 +204,38 @@ tc-is-softfloat() {
> > bfin*|h8300*)
> > echo "only" ;;
> > *)
> > - if [[ ${CTARGET//_/-} == *-softfloat-* ]] ; then
> > - echo "yes"
> > - elif [[ ${CTARGET//_/-} == *-softfp-* ]] ; then
> > - echo "softfp"
> > - else
> > - echo "no"
> > - fi
> > + case ${CTARGET//_/-} in
> > + *-softfloat-*)
> > + echo "yes" ;;
> > + *-softfp-*)
> > + echo "softfp" ;;
> > + arm*)
> > + # arm-unknown-linux-gnueabi is
> > ambiguous. We used to
> > + # treat it as hardfloat but we now
> > treat it as
> > + # softfloat like most everyone else.
> > However, we
> > + # check existing toolchains to avoid
> > breaking
> > + # existing systems, if possible.
> > + if type -P ${CTARGET}-cpp >/dev/null;
> > then
>
> I believe correct way to get cpp for target is
> "$(tc-getCPP ${CTARGET}) -E"
Good point. I was initially concerned about Clang but I guess we want
this to work the same way under Clang and apparently it does define the
same macros.
> > + if ${CTARGET}-cpp -E - <<<
> > __ARM_PCS_VFP 2>/dev/null | grep -q __ARM_PCS_VFP; then
>
> 4. This magic is hard to follow and reason about.
> I suggest moving out autodetection of current setup into another helper.
> Bonus point for detection of mismatch of actual vs. intended state.
Fair enough, it managed to confused mgorny. ;)
> Then we could start warning users about the fact of inconsistency and point
> to migration procedure. And we could have cleaner ${CTARGET} matches against
> what Gentoo expects.
Not sure about this. As I've said, I don't want to force users to
migrate. Would a warning be too annoying?
> 5. you don't use ${CFLAGS} here. I feel we should use them as people do
> occasionally
> override defaults.
I considered it but can we reliably get the flags for CTARGET?
> > + # Confusingly
> > __SOFTFP__ is defined only
> > + # when -mfloat-abi is
> > soft, not softfp.
> > + if ${CTARGET}-cpp -E -
> > <<< __SOFTFP__ 2>/dev/null | grep -q __SOFTFP__; then
> > + echo "softfp"
> > + else
> > + echo "yes"
> > + fi
> > + else
> > + echo "no"
> > + fi
> > + elif [[ ${CTARGET} == *-hardfloat-* ||
> > ${CTARGET} == *hf ]]; then
>
> I suggest using *-gnueabihf. I don't think anything more generic is
> recognized by toolchains
> as a hardfloat target.
There is also musleabihf and uclibceabihf. Would *eabihf be better?
> Also please link to description of what you think canonical hardfloat tuples
> are supposed to
> be. Upstreams do not agree on the definition.
I thought this was basically dictated by our profiles but okay.
> > + echo "no"
> > + else
> > + echo "yes"
> > + fi
> > + ;;
> > + *)
> > + echo "no" ;;
> > + esac
> > ;;
> > esac
> > }
> > --
> > 2.17.0
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpAtCPnQ1hnC.pgp
Description: OpenPGP digital signature
