Bug#289045: gcc-3.3: gcc packages do not use the alternative system
On Thu, 06 Jan 2005 23:38:08 +0100 Falk Hueffner [EMAIL PROTECTED] wrote: It is possible to have various versions of gccco installed, though none of the packages use the alternative system but a couple of unrelated symlinks in /usr/bin. Thus, these symlinks get overwritten on every update. Symlinks in /usr/bin belong to dpkg; you have no business changing them. So this is certainly not a critical bug. Ok, what is then the reason to allow multiple versions of gcc if i'm not allowed to change the default one ? I'm not sure whether gcc should be managed by an alternative; we already have cc as an alternative. I'll leave that for others to decide. It should, gcc is nothing different than vi or a window manager or a terminal emulation. Attila Kinali
Bug#289045: gcc-3.3: gcc packages do not use the alternative system
Attila Kinali [EMAIL PROTECTED] schrieb am 07.01.05 09:27:43: On Thu, 06 Jan 2005 23:38:08 +0100 Falk Hueffner [EMAIL PROTECTED] wrote: It is possible to have various versions of gccco installed, though none of the packages use the alternative system but a couple of unrelated symlinks in /usr/bin. Thus, these symlinks get overwritten on every update. Symlinks in /usr/bin belong to dpkg; you have no business changing them. So this is certainly not a critical bug. Ok, what is then the reason to allow multiple versions of gcc if i'm not allowed to change the default one ? The reason is to allow calling them by their name (like gcc-3.4), or to change the default compiler by means other than a symlink in /usr/bin, for example by putting them earlier in $PATH. Falk
Bug#289045: gcc-3.3: gcc packages do not use the alternative system
Attila Kinali [EMAIL PROTECTED] schrieb am 07.01.05 09:50:40: On Fri, 07 Jan 2005 09:35:55 +0100 Falk Hueffner [EMAIL PROTECTED] wrote: Attila Kinali [EMAIL PROTECTED] schrieb am 07.01.05 09:27:43: Ok, what is then the reason to allow multiple versions of gcc if i'm not allowed to change the default one ? The reason is to allow calling them by their name (like gcc-3.4), or to change the default compiler by means other than a symlink in /usr/bin, for example by putting them earlier in $PATH. Sorry, how am i supposed to change the default compiler if i'm not allowed to change the symlinks ? No, changing $PATH doesn't work as all gcc binaries are installed in /usr/bin. ln -s /usr/bin/gcc-3.4 /usr/local/bin/gcc Falk
Bug#289045: gcc-3.3: gcc packages do not use the alternative system
On Fri, 07 Jan 2005 09:35:55 +0100 Falk Hueffner [EMAIL PROTECTED] wrote: Attila Kinali [EMAIL PROTECTED] schrieb am 07.01.05 09:27:43: On Thu, 06 Jan 2005 23:38:08 +0100 Falk Hueffner [EMAIL PROTECTED] wrote: Symlinks in /usr/bin belong to dpkg; you have no business changing them. So this is certainly not a critical bug. Ok, what is then the reason to allow multiple versions of gcc if i'm not allowed to change the default one ? The reason is to allow calling them by their name (like gcc-3.4), or to change the default compiler by means other than a symlink in /usr/bin, for example by putting them earlier in $PATH. Sorry, how am i supposed to change the default compiler if i'm not allowed to change the symlinks ? No, changing $PATH doesn't work as all gcc binaries are installed in /usr/bin. Attila Kinali
Bug#289045: gcc-3.3: gcc packages do not use the alternative system
On Fri, 07 Jan 2005 09:56:04 +0100 Falk Hueffner [EMAIL PROTECTED] wrote: Sorry, how am i supposed to change the default compiler if i'm not allowed to change the symlinks ? No, changing $PATH doesn't work as all gcc binaries are installed in /usr/bin. ln -s /usr/bin/gcc-3.4 /usr/local/bin/gcc LOL, this is a joke ? Right ? So, everyone has has to symlink a dozen of binaries by hand into a totaly different directory because someone is too lazy to do it the right way ? Look, i don't mind if you say that the symlinks belong to the package managment. I don't mind if you say i'm not supposed to touch them by hand. But there is a default which version of gcc should be used. And if there is a default there should be a way to change _this_ default _with_out_ using a workaround. Attila Kinali
Bug#289045: gcc-3.3: gcc packages do not use the alternative system
Attila Kinali wrote: On Fri, 07 Jan 2005 09:56:04 +0100 Falk Hueffner [EMAIL PROTECTED] wrote: Sorry, how am i supposed to change the default compiler if i'm not allowed to change the symlinks ? No, changing $PATH doesn't work as all gcc binaries are installed in /usr/bin. ln -s /usr/bin/gcc-3.4 /usr/local/bin/gcc LOL, this is a joke ? Right ? No. So, everyone has has to symlink a dozen of binaries by hand into a totaly different directory because someone is too lazy to do it the right way ? Look, i don't mind if you say that the symlinks belong to the package managment. I don't mind if you say i'm not supposed to touch them by hand. But there is a default which version of gcc should be used. And if there is a default there should be a way to change _this_ default _with_out_ using a workaround. Read e.g. http://bugs.debian.org/119952 for an answer. Thiemo
Bug#289045: gcc-3.3: gcc packages do not use the alternative system
On Fri, 7 Jan 2005 14:15:38 +0100 Thiemo Seufer [EMAIL PROTECTED] wrote: Attila Kinali wrote: On Fri, 07 Jan 2005 09:56:04 +0100 Falk Hueffner [EMAIL PROTECTED] wrote: ln -s /usr/bin/gcc-3.4 /usr/local/bin/gcc LOL, this is a joke ? Right ? No. I still consider it to be one. Look, i don't mind if you say that the symlinks belong to the package managment. I don't mind if you say i'm not supposed to touch them by hand. But there is a default which version of gcc should be used. And if there is a default there should be a way to change _this_ default _with_out_ using a workaround. Read e.g. http://bugs.debian.org/119952 for an answer. I've read it and there is nothing that adresses any of my argument. It just states that it doesn't fit into your way of doing things. Breaking things isnt an issue, because 1) There are only 2 things that can break: C++ programs and kernel modules. 2) They can only break when compiling new programs/modules Though I'm compiling a lot of c++ programs with different gcc versions linking against the debian packages none of them broke. But when using a different compiler to compile modules than the kernel was compiled with, things will definitly break. 3) I as an admin, want to be able to set the default compiler, no matter what my distro was compiled with and i don't want to mess with PATH because it doesn't fit into your way of doing things. I want to be able to compile the kernel with that, compile my modules, my programs, everything with _my_ default (again w/o workarounding your way of doing things) Attila Kinali
Processed: Re: Bug#277206: gcc-3.3: internal error (segfault) while compiling Linux 2.6.9
Processing commands for [EMAIL PROTECTED]: merge 242916 277206 Bug#242916: [fixed in 3.4] ICE on invalid #define with -traditional Bug#277206: gcc-3.3: internal error (segfault) while compiling Linux 2.6.9 Merged 242916 277206. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#277206: gcc-3.3: internal error (segfault) while compiling Linux 2.6.9
merge 242916 277206 thanks Meelis Roos [EMAIL PROTECTED] schrieb am 07.01.05 16:45:19: I tracked it down to a vsyscall.S file containing only the line #define __builtin_warning(x, ...) (1) and compiling it with gcc -traditional -o vsyscall.s vsyscall.S causes the segfault. Ah, then it's a duplicate of #242916. Thanks for tracking this down. Falk
Bug#288817: apt-get and aptitude segfault on hppa
On Fri, Jan 07, 2005 at 08:56:04AM +0100, Matthias Klose wrote: hmm, the network card of my A500 is currently broken :-( Lamont, please could you check, if you can reproduce this? Dann, does recompiling apt fix the problem? I re-upgrade the box, which has been up for 45 days hasn't had any other significant upgrades, and I no longer see the segvs. Kyle McMartin tried to reproduce it on his sarge box and he couldn't either. I suppose this bug should be closed, since I see no path to root cause at the moment. If I see the problem again, I'll leave it in the broken state and try to get some toolchain folks to look at it.
Bug#187564: [Bug rtl-optimization/10692] [3.3/3.4/4.0 regression] [m68k] miscompilation of perl with -O2 -fPIC
--- Additional Comments From debian-gcc at lists dot debian dot org 2005-01-07 21:36 --- [tried to reopen the report, but didn't succeed, and You tried to change the Versions this fails on field from 3.3.3 3.4.0 4.0.0 to 3.3.3 3.4.0] The patch applies to the 3.3 branch as well and fixes the bug. Testsuite currently running. Ok for the 3.3 branch as well? Matthias -- What|Removed |Added CC||gdr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10692 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Bug#187564: [Bug rtl-optimization/10692] [3.3/3.4/4.0 regression] [m68k] miscompilation of perl with -O2 -fPIC
-- What|Removed |Added Known to fail|3.3.3 3.4.0 4.0.0 |3.3.3 3.4.0 Known to work||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10692 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Processed: tagging 288817
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.5 # no reasoning for the tag in the bug report tags 288817 - sarge Bug#288817: apt-get and aptitude segfault on hppa Tags were: sarge Tags removed: sarge End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
[Bug target/18987] [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From wilson at specifixinc dot com 2005-01-08 03:51 --- Subject: Re: [4.0 regression] [ia64] Extra '.restore sp' in tail call On Wed, 2004-12-22 at 14:47, debian-gcc at lists dot debian dot org wrote: --- Additional Comments From debian-gcc at lists dot debian dot org 2004-12-22 22:47 --- according to http://bugs.debian.org/286840 (if that's the same thing), this is broken in gcc-3.3 CVS and gcc-3.4 CVS as well. Latest known working version is gcc-3.3.5. The patch in question is PR 13158. I added it to mainline, but did not add it to gcc-3.4 CVS because technically it is not a regression, and hence the rules do not seem to permit me to add it there without special permission. For gcc-3.3 CVS, I need the branch maintainer's permission, and I did not get it, though I did not try very hard, so it isn't on the gcc-3.3 CVS branch either. Red Hat did add it to gcc-3_4-rhl-branch. Someone probably added it to the debian gcc sources as a patch on top of the FSF tree, so for gcc-3.3 and gcc-3.4 this will have to be fixed on the debian side by adding the patch in this PR also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug target/18987] [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From wilson at gcc dot gnu dot org 2005-01-08 03:55 --- David's patch looks correct to me. We only need this on mainline, as the precursor patch (PR 13158) is only on mainline. I will do a build and test and then check it in if all goes well. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2004-12-17 13:00:17 |2005-01-08 03:55:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug target/18987] [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-08 04:47 --- Subject: Re: [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call wilson at specifixinc dot com [EMAIL PROTECTED] writes: | according to http://bugs.debian.org/286840 (if that's the same thing), this is | broken in gcc-3.3 CVS and gcc-3.4 CVS as well. Latest known working version is | gcc-3.3.5. | | The patch in question is PR 13158. I added it to mainline, but did not | add it to gcc-3.4 CVS because technically it is not a regression, and | hence the rules do not seem to permit me to add it there without special | permission. For gcc-3.3 CVS, I need the branch maintainer's permission, | and I did not get it, though I did not try very hard, so it isn't on the | gcc-3.3 CVS branch either. Red Hat did add it to gcc-3_4-rhl-branch. I must have missed that patch then. | Someone probably added it to the debian gcc sources as a patch on top of | the FSF tree, so for gcc-3.3 and gcc-3.4 this will have to be fixed on | the debian side by adding the patch in this PR also. then, if it is 3.4.x it should go into 3.3.x too. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
