This is the mail archive of the
mailing list for the eCos project.
Re: GCC 4.6 resourcing.
- From: Ilija Kocho <ilijak at siva dot com dot mk>
- To: John Dallaway <john at dallaway dot org dot uk>
- Cc: ecos-maintainers at ecos dot sourceware dot org
- Date: Wed, 25 Jan 2012 00:40:19 +0100
- Subject: Re: GCC 4.6 resourcing.
- References: <4F1EF26A.firstname.lastname@example.org> <4F1F265B.email@example.com>
On 24.01.2012 22:44, John Dallaway wrote:
Ilija Kocho wrote:
I have a working version (Ubuntu 10.04 32bit) of gnutools (GCC 4.6.2,
Binutils 22.2, GDB 7.3.1) that I would put available for display/review.
This is my first such project so I have some questions:
If you are happy that your arm-eabi toolchain is functional (for targets
you have at your disposal), then I see no reason not to proceed with an
initial arm-eabi test release.
I have tested with Cortex-M targets so far, but the multi-libs seem to
build for same targets as 4.2.3 + additional FPU library for Cortex-M4.
Here's -print-multi-lib diff.
--- /tmp/multilib_4.3.2.out 2012-01-24 23:25:48.766547367 +0100
+++ /tmp/multilib_4.6.2.out 2012-01-24 23:25:48.770547367 +0100
@@ -23,3 +23,4 @@
It would be wise to try at least ARM7TDMI and ARM9 before we publish,
but I haven't such targets handy.
Does the backtrace for an eCos thread and for HAL startup code work
reliably with GDB 7.3.1? In the past, we have seen issues where the
backtrace code can enter an infinite loop, hence the patch for GDB 6.8.50.x.
I haven't patched GDB and I haven't tested GDB much, merely used it. The
7.3.1 rel. notes (and some former releases) mention some fixes regarding
How can one produce the case?
Note: GDB 7.4 has just been released. Should we aim for it or be
I would definitely recommend building for both Linux x86 and Cygwin x86
hosts so we reach all potential testers and get some feedback regarding
It would be good to have in mind several Linux distributions: My current
is Ubuntu 10.04 LTS but forthcoming 12.04 is LTS so we should consider
it too. Then Red Hat / Fedora ...
1. Where shall I put:
Since the sources are full binutils/gcc/gdb releases (not snapshots),
the only real issue is maintaining the patches.
Patches and toolchain binaries should be uploaded to the eCos ftp area.
Also http://ecos.sourceware.org/build-toolchain.html shall need refresh.
1.1. Regarding sources:
I am expecting (hope for) some collaboration so some VCS (CVS would do)
would be desirable. This may imply putting complete sources, which may
be an overkill... or not... Suggestions?
I don't think it should be necessary to place the toolchain sources
under revision control. In the past, we have simply generated tarballs
containing the various patches and placed them on the ftp site along
with the generated toolchains. Of course, there should be a separate
tarball of patches for each version of the toolchain.
I ask this question in order to define a way of sharing information
during development process. If tarballs do the job then it's OK.
I would suggest something like:
IMHO we should mark our tools and the right place is --with-pkgversion
(unless it isn't, please see my question below)..
My initial proposal is: "eCos Community [GNU]tools 4.6.2-<build>"
build = 0, 1, ...
[GNU] - optional: GNU | gnu | void
Feel free to comment and/or give your own proposals.
--with-pkgversion='eCos GNU tools 4.6.2-20120124'
Technical question: How do I get the complete (white-space) quote? I
have tried single', double" and backslash/ quoting and it only shows the
first word (eCos) such as:
23:55:11> arm-eabi-gcc --version
arm-eabi-gcc (eCos) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I have suitably old Linux and Cygwin installations here and can generate
releases based on your patches if you prefer.
Nice. Your production facilities would be a great help and some
assurance for stable builds.