Re: GCC 4.1 in experimental / GCC for etch

* Matthias Klose <[EMAIL PROTECTED]> [2006-02-21 02:44]: > - uploading GCC 4.1 to unstable for those architectures which do not > have ABI problems (these should be all, but should be validated). I just checked ARM using the extract-syms.sh script and it looks fine. -- Martin Michlmayr http://w

Re: GCC 4.1 in experimental / GCC for etch

> Please check that the symbols exported in the 4.1 libraries are a > superset of those exported in the 4.0 libraries (these are libgcc1 > (except m68k and hppa), libstdc++6, libffi4, libobjc1, libmudflap0). I ran a slightly modified version of your http://people.debian.org/~doko/extract-syms.sh o

Re: GCC 4.1 in experimental / GCC for etch

* Martin Michlmayr <[EMAIL PROTECTED]> [2006-03-04 00:43]: > I'm going to build 4.1.0-0 now. Both uploaded, logs available at http://people.debian.org/~tbm/logs/gcc-4.1_4.1.0-0/ Matthias and Thiemo, can you look at the results from the test suite? -- Martin Michlmayr http://www.cyrius.com/ --

Re: GCC 4.1 in experimental / GCC for etch

Matthias Klose wrote: > The GCC (GNU compiler collection) 4.1 release candidate 1 can be found > in experimental. "Porters", please make sure that the package is > built and uploaded (if it's not built by the experimental > buildd). Please check that the symbols exported in the 4.1 libraries > ar

Re: GCC 4.1 in experimental / GCC for etch

* Matthias Klose <[EMAIL PROTECTED]> [2006-02-21 02:44]: > The GCC (GNU compiler collection) 4.1 release candidate 1 can be > found in experimental. "Porters", please make sure that the package > is built and uploaded (if it's not built by the experimental > buildd). I built 4.1-0exp9 on mips and

Re: GCC 4.1 in experimental / GCC for etch

> - Stop building compiler packages from the GCC 3.3 source; the only > packages built will be libstdc++5 (and libgcc1 on hppa/m68k). > ... > - GCC 2.95 was requested to be shipped with etch. Currently alpha > FTBFS and needs to be disabled. g++-3.3 is the last version supporting a still-widel

Re: GCC 4.1 in experimental / GCC for etch

bian-gcc" debian-gcc@lists.debian.org,"debian-hppa" debian-hppa@lists.debian.org,"debian-release" debian-release@lists.debian.org Date : Wed, 22 Feb 2006 11:48:25 +0100 Subject : Re: GCC 4.1 in experimental / GCC for etch > Aurelien Jarno a écrit : > > Joe

Re: GCC 4.1 in experimental / GCC for etch

Aurelien Jarno a écrit : Joel Soete a écrit : Hello Aurelien, Hi ! Did you read it: This fix for me the pb when glibc was build with gcc-4.[01] Thanks for the hint. However I have just build a new glibc

Re: GCC 4.1 in experimental / GCC for etch

Joel Soete a écrit : Hello Aurelien, Hi ! Did you read it: This fix for me the pb when glibc was build with gcc-4.[01] Thanks for the hint. However I have just build a new glibc with this patch, and I still h

Re: GCC 4.1 in experimental / GCC for etch

ian-release@lists.debian.org Date : Wed, 22 Feb 2006 08:38:17 +0100 Subject : Re: GCC 4.1 in experimental / GCC for etch > [I have done s/ports/hppa/ in the Cc: list] > > Randolph Chung a écrit : > >>For hppa, the glibc builds well with gcc 4.0, but create problem wi

Re: GCC 4.1 in experimental / GCC for etch

[I have done s/ports/hppa/ in the Cc: list] Randolph Chung a écrit : For hppa, the glibc builds well with gcc 4.0, but create problem with python/perl. It still has to be investigated. Can you explain what the problems are (or at least the symptoms) so that we can look into them? Are there an

Re: GCC 4.1 in experimental / GCC for etch

> For hppa, the glibc builds well with gcc 4.0, but create problem with > python/perl. It still has to be investigated. Can you explain what the problems are (or at least the symptoms) so that we can look into them? Are there any bugs filed on this? thanks randolph -- Randolph Chung Debian GNU/L

Re: GCC 4.1 in experimental / GCC for etch

Matthias Klose <[EMAIL PROTECTED]> writes: > Still open points are > > - GNAT maintainance. Supposed to be based on 4.1. The GNAT maintainer > isn't a DD yet (after more than a year of GNAT maintainance in > Debian I'm loosing trust in our NM process). I'm that person. I started GNAT maintena

Re: GCC 4.1 in experimental / GCC for etch

Matthias Klose wrote: > - Once the 4.1 packages are migrated to testing, make 4.1 the default > compiler for i386, amd64, powerpc. GCC 4.1 has lightweight protective measures against stack overflows. Is this something that must be explicitly activated by maintainers through compiler flags or wil

Re: GCC 4.1 in experimental / GCC for etch

On Tue, Feb 21, 2006 at 11:34:55AM +0100, Aurelien Jarno wrote: > For m68k, the glibc does not build, gcc 4.0 segfault on system.c. It > looks like gcc 4.1 fixes the problem, but the resulting glibc has not > been tested. Many m68k ICEs are fixed by GCC 4.1. I intend to switch over quickstep (th

Re: GCC 4.1 in experimental / GCC for etch

On Tue, Feb 21, 2006 at 11:34:55AM +0100, Aurelien Jarno wrote: > >- Once the 4.1 packages are migrated to testing, make 4.1 the default > > compiler for i386, amd64, powerpc. These are the architectures, > > which are considred primary (linux) architectures by GCC upstream. > > For the other De

Re: GCC 4.1 in experimental / GCC for etch

Aurelien Jarno writes: > The GCC website seems to be down currently, could you please tell us > when the release are expected? as usually: when its ready. maybe in February. > > - Stop building compiler packages from the GCC 3.3 source; the only > > packages built will be libstdc++5 (and libgc

Re: GCC 4.1 in experimental / GCC for etch

Hi! Matthias Klose a écrit : The GCC (GNU compiler collection) 4.1 release candidate 1 can be found in experimental. "Porters", please make sure that the package is built and uploaded (if it's not built by the experimental buildd). Please check that the symbols exported in the 4.1 libraries are

GCC 4.1 in experimental / GCC for etch

The GCC (GNU compiler collection) 4.1 release candidate 1 can be found in experimental. "Porters", please make sure that the package is built and uploaded (if it's not built by the experimental buildd). Please check that the symbols exported in the 4.1 libraries are a superset of those exported in