From: Joern Rennecke <joern.rennecke@embecosm.com>
To: Joel Sherrill <joel.sherrill@oarcorp.com>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
Jan-Benedict Glaw <jbglaw@lug-owl.de>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
Michael Eager <eager@eagercon.com>
Subject: Re: [buildrobot] microblaze-elf / microblaze-linux
Date: Tue, 26 Nov 2013 19:50:00 -0000 [thread overview]
Message-ID: <CAMqJFCqBrFtWoq8sZH4tYhr6GCweSLNEQZZ2+mQEhx1Jx1tEKQ@mail.gmail.com> (raw)
In-Reply-To: <5294DC85.4030700@oarcorp.com>
On 26 November 2013 17:38, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> The key to seeing the value of testing *-rtems is moving
> beyond "builds or not" and into running tests on more
> languages.
Well, we are already configuring with --enable-languages=all,ada,go ,
so there are a lot of frontends being build - just not the libraries.
>
> as to Joern's question:
>> Is there something that microblaze-rtems exposes that is not already
>> covered by other microblaze or rtems targets that are already included?
>
> I believe it was on the microblaze where someone broke the
> libgcc pattern for rtems by changing the pattern from
> XXX*-*-* to XXX*-*-elf.
In order to catch such a problem, we'd have to at least build libgcc.
Which requires to have an assembler for the respective target first.
How should this be handled? Test if an cross-asembler for target
has been installedon the host?
Or having a separate list of targets that are supported by FSF GAS, and
a curent gas checkout, and then building gas for those targets?
next prev parent reply other threads:[~2013-11-26 19:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 12:35 Joel Sherrill
2013-11-26 14:51 ` Jan-Benedict Glaw
2013-11-26 15:21 ` Joern Rennecke
2013-11-26 15:28 ` Jan-Benedict Glaw
2013-11-26 16:03 ` Michael Eager
2013-11-26 16:52 ` Joseph S. Myers
2013-11-26 17:38 ` Joel Sherrill
2013-11-26 18:00 ` Ralf Corsepius
2013-11-26 18:54 ` Joel Sherrill
2013-11-26 19:50 ` Joern Rennecke [this message]
2013-11-26 19:54 ` Jan-Benedict Glaw
-- strict thread matches above, loose matches on Subject: below --
2013-11-26 3:20 [buildrobot] First results of running contrib/config-list.mk Jan-Benedict Glaw
2013-11-26 3:27 ` [buildrobot] microblaze-elf / microblaze-linux Jan-Benedict Glaw
2013-11-26 15:51 ` Michael Eager
2013-11-26 16:08 ` Jan-Benedict Glaw
2013-11-26 16:13 ` Michael Eager
2013-11-26 16:17 ` Jan-Benedict Glaw
2013-11-26 17:16 ` Michael Eager
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=CAMqJFCqBrFtWoq8sZH4tYhr6GCweSLNEQZZ2+mQEhx1Jx1tEKQ@mail.gmail.com \
--to=joern.rennecke@embecosm.com \
--cc=eager@eagercon.com \
--cc=gcc@gcc.gnu.org \
--cc=jbglaw@lug-owl.de \
--cc=joel.sherrill@oarcorp.com \
--cc=joseph@codesourcery.com \
/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).