[no subject]
Subscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 Debian architectures, the GCC port maintainers and the > > Debian port maintainers should make the call, if and when the > > default GCC is changed. > > I think you could also make 4.1 the default one for kfreebsd-i386. They > are very few differences with the linux version, and the testsuite shows > good results. Agreed, but.. (see below) > >- Stop building compilers from GCC 3.4.x, namely gobjc-3.4, gnat-3.4 > > and g++-3.4 (it looks like we can go without g++-3.4 for the etch > > release). Still build gpc-3.4, g77-3.4 and gcc-3.4, as g77 cannot be > > found anymore in 4.x releases. > > Currently three architectures are still using gcc 3.4 to build the > glibc, namely m68k, hppa and powerpc. Building kfreebsd-5 (and kfreebsd-6, etc) requires gcc-3.4 as well. Note that upstream only supports their own fork of gcc-3.4 to build the kernel, and I'm not aware of any plans to update it short-term. So AFAIK no problem on our side to make gcc-4.1 the default, as long as gcc-3.4 is still present. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.15-1-sparc64 issues on blade 100
"Luis F. Ortiz" <[EMAIL PROTECTED]> writes: > So I took a peek at the reference clock chip (X7) and it is a 29.4 > Mhz clock. The same with mine, I think, though it's rather indistinct. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 a superset of those exported in the 4.0 libraries (these are libgcc1 (except m68k and hppa), libstdc++6, libffi4, libobjc1, libmudflap0). The proposed GCC plan for etch consists of: - uploading GCC 4.0.3 to unstable (this release is expected shortly after the GCC 4.1.0 release), let 4.0.3 migrate to testing. The GCC website seems to be down currently, could you please tell us when the release are expected? - uploading GCC 4.1 to unstable for those architectures which do not have ABI problems (these should be all, but should be validated). Nice! - 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 Debian architectures, the GCC port maintainers and the Debian port maintainers should make the call, if and when the default GCC is changed. I think you could also make 4.1 the default one for kfreebsd-i386. They are very few differences with the linux version, and the testsuite shows good results. - Make gij-4.1/gcj-4.1 the default for all architectures. - Stop building compiler packages from the GCC 3.3 source; the only packages built will be libstdc++5 (and libgcc1 on hppa/m68k). AFAIK the 2.4 kernels in Debian are built with gcc-3.3. What are the plans wrt to them? - Stop building compilers from GCC 3.4.x, namely gobjc-3.4, gnat-3.4 and g++-3.4 (it looks like we can go without g++-3.4 for the etch release). Still build gpc-3.4, g77-3.4 and gcc-3.4, as g77 cannot be found anymore in 4.x releases. Currently three architectures are still using gcc 3.4 to build the glibc, namely m68k, hppa and powerpc. For powerpc, it seems we can make the switch to at least gcc 4.0. There is currently a problem of locales, but not sure it is related to gcc-4.0. For hppa, the glibc builds well with gcc 4.0, but create problem with python/perl. It still has to be investigated. 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. I think compilers are critical for the glibc, so we will have to coordinate the changes. Aurélien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sparc64 smp halt
Quoting Blars Blarson <[EMAIL PROTECTED]>: > I switched my ultra-2 to a serial console so I could capture the oops > when I ran into the sparc64 smp halting bug again. The message is: > > RED State Exception I had this once if I recall correctly. It isn't software curable (that I could find). Look at google. 'They' say that it's either a memory problem (faulty/broken memory), CPU problem (ditto) or MB problem (ditto again!). In my case it was a broken CPU. It broke when I installed a firmware patch... Yes, you read correctly! See the following URL: http://supportforum.sun.com/hardware/index.php?t=msg&th=1814 I managed to get Sun to replace the CPU free of charge even without having a support contract... Don't think they had much choise. I'm quite sure I had the law on my side that time, but I'm still _very_ (can't over state that enough!) greatfull that they did it... -- KGB Honduras munitions SEAL Team 6 smuggle AK-47 NSA 767 strategic toluene [Hello to all my fans in domestic surveillance] $400 million in gold bullion Rule Psix assassination Ft. Meade [See http://www.aclu.org/echelonwatch/index.html for more about this] [Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf] If neither of these works, try http://www.aclu.org and search for echelon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
