public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: crossgcc@sourceware.org
Cc: Willy Tarreau <w@1wt.eu>
Subject: Re: scripts: add support for overriding the arch name in the tuple
Date: Sun, 20 Jan 2013 23:30:00 -0000	[thread overview]
Message-ID: <201301210030.18760.yann.morin.1998@free.fr> (raw)
In-Reply-To: <20130120225822.GS6838@1wt.eu>

Willy, All,

On Sunday 20 January 2013 Willy Tarreau wrote:
> it sometimes happens that I need to build toolchains for several variants
> of a CPU and I want to have the variant name in the arch tuple. In fact,
> this is very similar to what is done with i386/i486/i586/i686, all of them
> being variants of the x86 arch family.
> 
> On arm, we commonly see armv5/armv6/armv7 and with v7 there are two common
> cpus which are cortex a8 and a9.
> 
> So I'm used to build my toolchains with a prefix which is 'armv5te',
> 'armv7a8', 'armv7a9' etc...
> 
> For this I wrote the small patch below for ct-ng-1.15.3, which still works
> with 1.17.0.
> 
> On one of my machines, the toolchain directory looks like this, which is
> quite convenient to use :
> 
>   arm-gcc43_glibc29-linux-gnueabi/
>   arm-gcc44_glibc29-linux-gnueabi/
>   arm-gcc45_glibc29-linux-gnueabi/
>   armv7a8-gcc43_glibc29-linux-gnueabi/
>   armv7a9-gcc44_glibc29-linux-gnueabi/
>   armv7a9-gcc47_glibc29-linux-gnueabi/
>   armv7a9-gcc47_glibc29-linux-gnueabihf/

How do you managfed to have a '*-gnueabihf' with crosstool-NG?
Last I tested, gcc broke because it did not recognise it as an EABI
variant, and would not include the EABI file in gcc/config/arm/ .

Even with a bit of patching, I ended up in a few hiccups here and there,
so that's why ct-ng does not set the tuple to '*-gnueabihf' for now for
ARM hard-float ABI.

>   i386-gcc34_glibc23-linux-gnu/
>   x86_64-gcc34_glibc23-linux-gnu/
> 
> Hoping someone finds the patch useful.

A few comments:
  - missing SoB line
  - provide a more terse commit-log, eg something like:
    ---8<---
    arch: provide a arch-override for the tuple

    For some architectures, it is legit to have an alternate value in the
    'architecture' part of the tuple. For example:
        armv5te-*
        armv7a8-*

    Besides, some packages expect the tuple to reflect the arch variant
    (eg. openMPI) to detect the variant's capabilities (eg. atomic
    primitives).

    We already have this for x86 (i[3456]86-*), but it is not possible
    for other archs.

    This patch provides an overide mechanism

    Signed-off-by: You you@there
    ---8<---
    
> diff -urN ./config/target.in ./config/target.in
> --- ./config/target.in.orig	2012-07-17 22:39:55.000000000 +0200
> +++ ./config/target.in	2012-07-27 12:02:08.682588639 +0200
> @@ -5,6 +5,17 @@
>  config ARCH
>      string
>  
> +config ARCH_OVERRIDE
> +    string
> +    prompt "Arch name to use in the resulting tuple instead of ${CT_ARCH}"
> +    help
> +      Some architectures have multiple variants and being able to specify
> +      the variant instead of the arch is quite convenient. This is commonly
> +      seen for instance when "armv5tel-" is used as a prefix instead of the
> +      more generic "arm-", or with "alphaev6-" instead of "alpha-".
> +
> +      If you're not sure about what this is, leave it blank.
> +

I think we should not allow the user to completely overide the arch-part.
We should just allow for appending to the arch-part. This would be added
to the default tuple, and would not create symlinks as the two other
options currently do, so it would be possible to install more than one
toolchain in the same place, as the default tuples would all be different
(maybe that's what I did not completely explain during our private
exchange).

Thus, CT_TARGET_ARCH_SUFFIX="v5te" would give a tuple starting with
"armv5te-".

IMHO, giving the user the ability to completely overide the arch-part is
opening the door to complete mayhem. I'm a bit uneasy with that.

[--SNIP--]
> diff -urN ./scripts/functions ./scripts/functions
> --- ./scripts/functions.orig	2012-07-17 22:39:55.000000000 +0200
> +++ ./scripts/functions	2012-07-27 11:57:19.903088370 +0200
> @@ -982,7 +982,7 @@
>      esac
>  
>      # Build the default architecture tuple part
> -    CT_TARGET_ARCH="${CT_ARCH}"
> +    CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH}}"

Here, we'd have:
    CT_TARGET_ARCH="${CT_ARCH}${CT_TARGET_ARCH_SUFFIX}"

And similar for the architectures. Which would ensure the default tuple
will include this arch-part suffix.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

  reply	other threads:[~2013-01-20 23:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-20 22:58 Willy Tarreau
2013-01-20 23:30 ` Yann E. MORIN [this message]
2013-01-20 23:48   ` Willy Tarreau
2013-01-21 18:10     ` Yann E. MORIN
2013-01-21 18:58       ` Willy Tarreau
2013-01-22  0:11 ` arch: allow adding a suffix to the arch-part of a tuple Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201301210030.18760.yann.morin.1998@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=crossgcc@sourceware.org \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).