Package: gcc-3.3
Version: 1:3.3.4-13
Tags: patch
This was sent to debian-ia64, I'm filing the appropriate bugs for it.
Including this patch would be a great help.
- Forwarded message from David Mosberger [EMAIL PROTECTED] -
I have grown increasingly concerned that even with the current
On Mon, Jun 28, 2004 at 07:08:36PM +0200, Matthias Klose wrote:
hppa is the only platform with gcc-3.0/g++-3.0. Is this version still
needed for hppa builds, or can it be removed? On all other platforms,
we just build the libstdc++ runtime library (but doesn't seem to be
needed, I haven't seen
On Sun, Jan 25, 2004 at 11:03:53AM -0700, Grant Grundler wrote:
On Sun, Jan 25, 2004 at 06:05:17PM +0100, Willy Tarreau wrote:
But the root of the problem lies in gcc 3.0.4 since it is OK in 3.3.2. So
wouldn't it be easier to identify and backport the fix from 3.3.2 to 3.0.4
and inform all
On Wed, Dec 17, 2003 at 09:03:16PM -0500, Nathanael Nerode wrote:
Matthias Klose wrote:
gcc-3.3 is configured with --enable-sjlj-exceptions (done to keep
compatibility with gcc-3.2). I don't know if the dwarf2 unwinder will
work with this setup.
To be much more specific, it is configured
On Sat, Aug 09, 2003 at 03:32:12PM +0900, GOTO Masanori wrote:
At Sat, 9 Aug 2003 02:52:01 +0100,
Matthew Wilcox wrote:
[EMAIL PROTECTED]:~$ sudo /etc/init.d/apache start
Starting web server: apache/etc/init.d/apache: line 70: 29184 Segmentation
fault start-stop-daemon --start
Package: gcc-defaults
Version: 1.8
Severity: serious
Architecture: ia64
Automatic build of gcc-defaults_1.8 on caballero by sbuild/ia64 1.170.4
Build started at 20030811-0235
**
[...]
dh_installchangelogs -pcpp
mv
On Wed, May 21, 2003 at 01:42:53AM +0200, Matthias Klose wrote:
For Debian GNU/Linux gcc-3.3 is currently configured with
--with-sjlj-exceptions
to allow a binary compatible upgrade from gcc-3.2 to gcc-3.3. The
other Debian platform, where sjlj based exceptions changed to dwarf2
On Sun, Mar 02, 2003 at 09:36:17AM +, Matthew Wilcox wrote:
Second problem: dependencies in the debian/control file. They probably
look something like this:
Build-Depends: gnat (= 3.14p-1), gnat ( 3.15)
and
Depends: gnat (= 3.14p-1), gnat ( 3.15)
What should these look like
On Sun, Mar 02, 2003 at 11:33:18AM +0100, Florian Weimer wrote:
Please drop shared library support altogether. It is currently not
worth the trouble. GNAT ABIs change from version to version, and the
run-time library can be built only with the corresponding version of
the compiler. This
Package: gcc-3.2
Version: 3.2.1ds5-0pre6
Severity: minor
I was just reviewing the .diff.gz to prove a point (Debian diverges
significantly from upstream! Does not! Does too! Does not!) and I
noticed several files were present in CVS conflict version; ie:
+++
On Fri, Aug 16, 2002 at 09:59:28AM -0700, Sean 'Shaleh' Perry wrote:
* Add a Conflict with the non-`c' version of the package.
why can't we have both installed, just like the libfoo6 and libfoo6g
situation??
i explained this elsewhere...
Why don't we put the libs in a different
On Tue, May 07, 2002 at 01:38:22PM +0100, Matthew Wilcox wrote:
On Monday 06 May 2002 20:35, Matthew Wilcox wrote:
I guess I'll try mips, mipsel s390 next -- sparc powerpc should be
able to bootstrap themselves without additional effort.
I'm told s390 is already done -- cool. Just
On Thu, May 09, 2002 at 04:38:31PM -0400, Christopher C. Chimelis wrote:
FYI, I'm getting MUCH farther using Matthias' new gcc-3.1 pre packages as
the native compiler for i386 building the cross compiler for alpha. I
suspect that 2.95.4 may have issues with building 32-64 cross compilers
that
On Thu, May 09, 2002 at 05:01:32PM -0400, Christopher C. Chimelis wrote:
On Thu, 9 May 2002, Matthew Wilcox wrote:
Yep, I managed to cross-build everything to alpha from x86 and then it
even compiled itself a few times. it was only trying to compile some
auxiliary Ada programs where we
I've tried building m68k-linux, arm-linux and alpha-linux gnat compilers.
None has worked ;-( ARM and m68k seem to be missing some exception handling
support, eg (arm):
../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2
-fomit-frame-pointer -fPIC -DIN_RTS |sed -e 's/-pedantic//g'
On Fri, Apr 26, 2002 at 07:36:47PM +0200, Matthias Klose wrote:
Did you try building the gnat compiler with native built compiler?
I did a make bootstrap which uses the compiler itself for the second
and third stages ...
--
Revolutions do not require corporate support.
--
To UNSUBSCRIBE,
The followup to #120333 indicates this is a bug with g++; is anyone
looking into this? i see no discussing on debian-gcc about it, but i'm
reluctant to simply reassign it to gcc.
--
Revolutions do not require corporate support.
On Wed, Oct 31, 2001 at 04:27:17PM -0800, Jim Wilson wrote:
extern inline means emit this function inline if you can, otherwise emit
nothing. Since gcc makes no promise that it will inline any function, it
is inherently unsafe to put extern inline in a C file. There is no guarantee
that it
On Sun, Aug 19, 2001 at 12:07:27PM +0200, Reinhard Gimbel wrote:
After successfully installing palinux-0.9.2 on my 715/64
I'm looking for the compilers (c, c++) ...
It looks like you didn't add the debian apt sources to your
/etc/apt/sources.list. binutils is at 2.11.90.0.27-1 currently,
for
19 matches
Mail list logo
