David Mosberger writes:
> I wanted to try this but found that the gcc-3.3 has a libgcc1 package
> for hppa only. Is this intentional? I thought a new libgcc1 package
> for ia64 was needed so we pick up the libunwind built from the
> libunwind sources.
please get the libgcc1 package from the unst
David Mosberger writes:
> >>>>> On Mon, 13 Dec 2004 20:47:41 +0100, Matthias Klose <[EMAIL PROTECTED]>
> >>>>> said:
> Matthias> It's currently built by the gcc-3.4 sources and includes
> Matthias> the libunwind.so.7 shared library
cript, on
advice of Jeff Bailey. Closes: #284563.
-- Matthias Klose <[EMAIL PROTECTED]> Fri, 10 Dec 2004 11:05:00 -0800
diff -u glibc-2.3.2.ds1/debian/control.in/main
glibc-2.3.2.ds1/debian/control.in/main
--- glibc-2.3.2.ds1/debian/control.in/main
+++ glibc-2.3.2.ds1/debian/co
H. J. Lu writes:
> On Thu, Dec 09, 2004 at 12:49:38PM +0100, Matthias Klose wrote:
> > H. J. Lu writes:
> > > On Tue, Dec 07, 2004 at 12:16:56AM -0800, David Mosberger wrote:
> > > > >>>>> On Tue, 7 Dec 2004 09:01:33 +0100, Matthias
David Mosberger writes:
> >>>>> On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose <[EMAIL PROTECTED]>
> >>>>> said:
>
> Matthias> glibc now fails to build from source:
>
> Matthias> undefined reference to `__gcc_personality_
H. J. Lu writes:
> On Tue, Dec 07, 2004 at 12:16:56AM -0800, David Mosberger wrote:
> > >>>>> On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose <[EMAIL PROTECTED]>
> > >>>>> said:
> >
> > Matthias> glibc now fails
Package: glibc
Severity: serious
glibc build failure on ia64 ...
gcc-3.3 -nostdlib -nostartfiles -static -o
/build/buildd/glibc-2.3.2.ds1/build-tree/ia64-nptl/elf/sln
/build/buildd/glibc-2.3.2.ds1/build-tree/ia64-nptl/csu/crt1.o
/build/buildd/glibc-2.3.2.ds1/build-tree/ia64-nptl/csu/crti.o `
not
+use C99 designators, as C++ does not have support for them.
+
+ -- Matthias Klose <[EMAIL PROTECTED]> Mon, 29 Nov 2004 00:11:44 +0100
diff -u glibc-2.3.2.ds1/debian/patches/00list
glibc-2.3.2.ds1/debian/patches/00list
--- glibc-2.3.2.ds1/debian/patches/00list
+++ glibc-2.3.2.ds1/
Matthieu Delahaye writes:
> On Wed, 2004-11-24 at 17:36, Ian Wienand wrote:
> > On Wed, Nov 24, 2004 at 12:46:12AM +0100, Matthias Klose wrote:
> > > ok, Ian, if it's ok with you, I'll prepare a libunwind upload, which
> > > plays well with a libgcc1 pa
David Mosberger writes:
> >>>>> On Wed, 24 Nov 2004 00:26:01 +0100, Matthias Klose <[EMAIL PROTECTED]>
> >>>>> said:
>
> Matthias> From my point of view we can get around with it by
> Matthias> including the libunwind shared library in
David Mosberger writes:
> >>>>> On Tue, 23 Nov 2004 09:27:52 +0100, Matthias Klose <[EMAIL PROTECTED]>
> >>>>> said:
>
> Matthias> Is the patch in #278836 a prerequisite for the above
> Matthias> changes, or can it be done without it?
Ian Wienand writes:
> On Mon, Nov 22, 2004 at 05:30:38PM -0800, David Mosberger wrote:
> > That would make sense. libstdc++5 calls _Unwind_Resume() which
> > is/should be implemented by libunwind.so.7. With older versions of
> > GCC, it was implemented as part of libgcc_eh.a/libgcc_s.so.
>
> Act
Package: glibc
Severity: serious
Tags: sid
current mainline libgcj fails to build on mips{,el}:
/home/doko/gcc/gcc-snapshot-20041003/build/gcc/xgcc -shared-libgcc
-B/home/doko/gcc/gcc-snapshot-20041003/build/gcc/ -nostdinc++
-L/home/doko/gcc/gcc-snapshot-20041003/build/mipsel-linux-gnu/libstdc+
Thomas Bushnell BSG writes:
>
> On behalf of Debian QA:
>
> Matthias, you reopened bug 266598 which according to Blars Blarson was
> fixed, and there is no indication in the reopen message why. Was this
> a mistake?
No. I did build glibc using binutils 2.14.x and did upload it to
unstable. So i
Package: qt-x11-free
Version: 3:3.3.3-4
Severity: serious
[please don't reassign yet, let's evaluate it first; this is the
package that most people would expect to find a report]
when building on arm-linux, uic enters an infinite loop building
pixmapfunction.h. It's not the first uic invocation
severity 263601 + serious
thanks
according to Dan binutils won't be fixed/cannot be fixed for
sarge. Please apply this workaround.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The bug submitter claims that a missing /proc leads to ICE's in gcc
and thinks this might be a bug in glibc or gcc. Any ideas? I'm unable
to reproduce this one.
Matthias
The bug submitter claims that a missing /proc leads to ICE's in gcc
and thinks this might be a bug in glibc or gcc. Any ideas? I'm unable
to reproduce this one.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On http://people.debian.org/~doko/gcc-3.[34] you find packages with a
setup to build biarch compilers on powerpc (which needs a 64bit glibc
as a build dependency).
- gcc-3.3: added a patch to build from the hammer branch (3.3.4). This
works on i386, fails on amd64, powerpc unknown. edit
debian
On http://people.debian.org/~doko/gcc-3.[34] you find packages with a
setup to build biarch compilers on powerpc (which needs a 64bit glibc
as a build dependency).
- gcc-3.3: added a patch to build from the hammer branch (3.3.4). This
works on i386, fails on amd64, powerpc unknown. edit
debian
Package: glibc
[submitted for keeping track of
http://lists.debian.org/debian-glibc/2004/debian-glibc-200404/msg00035.html]
This patch applied upstream
http://sources.redhat.com/ml/libc-hacker/2003-12/msg00025.html
is supposed to fix about 900 test failures in the libjava testsuite in
gcc-3.4. N
Package: glibc
[submitted for keeping track of
http://lists.debian.org/debian-glibc/2004/debian-glibc-200404/msg00035.html]
This patch applied upstream
http://sources.redhat.com/ml/libc-hacker/2003-12/msg00025.html
is supposed to fix about 900 test failures in the libjava testsuite in
gcc-3.4. N
Sven Luther writes:
> That said, i have close to zero deep understanding on how glibc and gcc
> interact on this issue, and what is going on about libgcc. I am told by
> the #ppc64 folk that i should compile gcc with the ppc64 target, but
> have it default to 32bit code by default. My early tries f
This patch applied upstream
http://sources.redhat.com/ml/libc-hacker/2003-12/msg00025.html
is supposed to fix about 900 test failures in the libjava testsuite in
gcc-3.4. Note that I didn't test the patch myself.
Matthias
Compare the Debian test results
http://gcc.gnu.org/ml/gcc-testresul
Sven Luther writes:
> First, i found that this gcc-3.4 package in experimental wasn't yet
> built on powerpc, which i did. It did output lot of FAILs in the tests
> later on, but i am not sure this is worrying or not.
Please have a look at http://gcc.gnu.org/ml/gcc-testresults/ and compare.
> It
Package: glibc
To build the hppa -> hppa64 cross compiler needed to build hppa64
kernels, the target specific headers are needed. Currently it's good
enough to symlink /usr/hppa64-linux/include to /usr/include.
Please include this symlink in the libc6-dev package for hppa or build
a new lib64c6-d
Karolina Lindqvist writes:
> lördagen den 7 februari 2004 18.01 you wrote:
> > This is not a bug, i386 support is dropped, gcc is configured to
> > generate code for i486 and up. IIRC the kernel binaries for i386 do
> > have a patch for emulation support for non-i386 instructions.
>
> So it's not
Karolina Lindqvist writes:
> lördagen den 7 februari 2004 18.01 you wrote:
> > This is not a bug, i386 support is dropped, gcc is configured to
> > generate code for i486 and up. IIRC the kernel binaries for i386 do
> > have a patch for emulation support for non-i386 instructions.
>
> So it's not
This is not a bug, i386 support is dropped, gcc is configured to
generate code for i486 and up. IIRC the kernel binaries for i386 do
have a patch for emulation support for non-i386 instructions.
This is not a bug, i386 support is dropped, gcc is configured to
generate code for i486 and up. IIRC the kernel binaries for i386 do
have a patch for emulation support for non-i386 instructions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAI
Colin Watson writes:
> On Sun, Jan 25, 2004 at 12:07:11PM +0100, Matthias Klose wrote:
> > Tobias writes:
> > > Attached is a small script that shows the difference between the too.
> > > Personally I think the tcsh is better sorted because of the differenc
Colin Watson writes:
> On Sun, Jan 25, 2004 at 12:07:11PM +0100, Matthias Klose wrote:
> > Tobias writes:
> > > Attached is a small script that shows the difference between the too.
> > > Personally I think the tcsh is better sorted because of the differenc
Tobias writes:
> Attached is a small script that shows the difference between the too.
> Personally I think the tcsh is better sorted because of the difference
> between "A" and "a".
bash's behaviour is different than tcsh, dash, zsh, ksh.
bash --norc
LANG=sv_SE
power-post-setup.bmp
ls: [A-Z][A
Tobias writes:
> Attached is a small script that shows the difference between the too.
> Personally I think the tcsh is better sorted because of the difference
> between "A" and "a".
bash's behaviour is different than tcsh, dash, zsh, ksh.
bash --norc
LANG=sv_SE
power-post-setup.bmp
ls: [A-Z][A
Package: glibc
Version: 2.3.2.ds1-10
Tags: patch
Please find attached a patch by Thiemo Seufer, which allows building
java (in gcc-snapshot) on the mips platform. Guido Guenther will
forward the bug upstream.
#! /bin/sh -e
# All lines beginning with `# DP:' are a description of the patch.
# DP:
Package: glibc
Version: 2.3.2.ds1-10
Tags: patch
Please find attached a patch by Thiemo Seufer, which allows building
java (in gcc-snapshot) on the mips platform. Guido Guenther will
forward the bug upstream.
#! /bin/sh -e
# All lines beginning with `# DP:' are a description of the patch.
# DP:
Andreas Metzler writes:
> BTW, does anybody know why glibc's dependencies are that strict, i.e.
> why locales depends on the exact same version of libc6? I am sure that
> compability breaks at some point but I wonder if e.g. locales 2.3.2.ds1-10
> would not run fine with libc6 2.3.2.ds1-9.
see #20
Andreas Metzler writes:
> BTW, does anybody know why glibc's dependencies are that strict, i.e.
> why locales depends on the exact same version of libc6? I am sure that
> compability breaks at some point but I wonder if e.g. locales 2.3.2.ds1-10
> would not run fine with libc6 2.3.2.ds1-9.
see #20
reassign 214692 g++-3.3
reassign 214694 g++-3.3
severity 214692 normal
severity 214694 normal
merge 214692 214694
retitle 214694 g++-3.3 (3.3.2) should depend on gcc-3.3 (>= 3.3.2)
thanks
xiphmont writes:
>
>
>
> On Wed, Oct 08, 2003 at 07:09:19AM +0200, Matthias Klose wrote:
tags 214694 + unreproducible
thanks
unable to reproduce. what is the contents of confdefs.h?
xiphmont writes:
> Package: gcc-3.3
> Version: 1:3.3.2-0pre5
> Severity: grave
> Tags: sid
> Justification: renders package unusable
>
> I apologize for originally filing this against libc6-dev; I see
>
reassign 214692 g++-3.3
reassign 214694 g++-3.3
severity 214692 normal
severity 214694 normal
merge 214692 214694
retitle 214694 g++-3.3 (3.3.2) should depend on gcc-3.3 (>= 3.3.2)
thanks
xiphmont writes:
>
>
>
> On Wed, Oct 08, 2003 at 07:09:19AM +0200, Matthias Klose wrote:
tags 214694 + unreproducible
thanks
unable to reproduce. what is the contents of confdefs.h?
xiphmont writes:
> Package: gcc-3.3
> Version: 1:3.3.2-0pre5
> Severity: grave
> Tags: sid
> Justification: renders package unusable
>
> I apologize for originally filing this against libc6-dev; I see
>
Package: libc6
Version: 2.3.2-2
Severity: serious
This is strange... I am able to reproduce this. Something to do with
the new glibc (on i386 only?)?
- Packages built yesterday (using python2.3-3) are ok, see gadly in
http://ftp-master.debian.org/~doko/python/
- The same package built after th
[CC to Andreas]
GOTO Masanori writes:
> At Thu, 7 Aug 2003 08:08:24 +0200,
> Matthias Klose wrote:
> >
> > [CCing m68k, if the new results look acceptable]
> >
> > GOTO Masanori writes:
> > > Hi Matthias,
> > >
> > > At S
Package: locales
Version: 2.3.2-2
Severity: important, maybe serious
At least in the changelog I don't see an entry that the dependency on
glibc-2.3.2-2 with the same Debian release number is actually needed.
Please decouple this tight dependency. It breaks at least building all
packages which ru
GOTO Masanori writes:
> At Sat, 9 Aug 2003 14:49:27 +0200,
> Matthias Klose wrote:
> > Please decouple this tight dependency. It breaks at least building
> > all packages which run a testsuite with locale dependent tests.
>
> Well, however, I've recognized this is p
here is a small example:
--- begin foo.py ---
def foo(s):
print s
--- end foo.py ---
--- begin setup.py ---
from distutils.core import setup
setup(name="foo",
version="1.0",
py_modules=["foo"])
--- end setup.py ---
$ python setup.py build
running build
running build_py
creating b
[CCing m68k, if the new results look acceptable]
GOTO Masanori writes:
> Hi Matthias,
>
> At Sun, 9 Mar 2003 08:26:52 +0100,
> Matthias Klose wrote:
> > Package: libc6-dev
> > Version: 2.3.1
> > Severity: grave
> >
> > Attached is a diff of a binutils b
[CCing m68k, if the new results look acceptable]
GOTO Masanori writes:
> Hi Matthias,
>
> At Sun, 9 Mar 2003 08:26:52 +0100,
> Matthias Klose wrote:
> > Package: libc6-dev
> > Version: 2.3.1
> > Severity: grave
> >
> > Attached is a diff of a binutils b
Jeff Bailey writes:
> That's why I sent you the message asking you about the binutils release
> from today.
see http://ftp-master.debian.org/~doko/binutils/
but the installation fails. not yet sure why ...
Jeff Bailey writes:
> That's why I sent you the message asking you about the binutils release
> from today.
see http://ftp-master.debian.org/~doko/binutils/
but the installation fails. not yet sure why ...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble?
what's happening there? an unreleased version on a buildd? this breaks
all packages build-depending on locales.
Matthias
what's happening there? an unreleased version on a buildd? this breaks
all packages build-depending on locales.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
James Troup writes:
> GOTO Masanori <[EMAIL PROTECTED]> writes:
> > Matthias, could you tell me that --enable-sjlj-exception is really
> > needed for some archs?
arm still uses sjlj based exceptions in 3.3, so there is at least one
arch which does not have a choice.
> Yes, it's needed. If we don
James Troup writes:
> GOTO Masanori <[EMAIL PROTECTED]> writes:
> > Matthias, could you tell me that --enable-sjlj-exception is really
> > needed for some archs?
arm still uses sjlj based exceptions in 3.3, so there is at least one
arch which does not have a choice.
> Yes, it's needed. If we don
Goto,
please wait two days, until
- gcc-3.3 moves to testing (uploaded for mipsel, currently building
for mips)
- gcc-defaults is uploaded to make gcc to point to gcc-3.3
- binutils-2.14.90.0.1 is uploaded (and we can enable gcc-3.3 and
glibc for x86-64)
I don't know if we should wait for
You can find packages of binutils-2.14.90.0.1 for alpha, arm, hppa,
ia64, i386, m68k, powerpc, sparc and s390 on
http://ftp-master.debian.org/~doko/binutils/
These packages fix at least some important reports. In the same
directory there is a README.test-summaries, which compares the tes
James Troup writes:
> Clint Adams <[EMAIL PROTECTED]> writes:
>
> > -MYCC = gcc-3.2 -m64
> > +MYCC = gcc-3.3 -m64
>
> Don't forget a build-depends on gcc-3.3 if you do this...
I would like to wait with the next upload until the current 3.2
packages move to testing, if this happens this week. Jus
James Troup writes:
> Clint Adams <[EMAIL PROTECTED]> writes:
>
> > -MYCC = gcc-3.2 -m64
> > +MYCC = gcc-3.3 -m64
>
> Don't forget a build-depends on gcc-3.3 if you do this...
I would like to wait with the next upload until the current 3.2
packages move to testing, if this happens this week. Jus
Daniel Jacobowitz writes:
> On Sun, Mar 09, 2003 at 09:24:50AM +0100, Matthias Klose wrote:
> > GOTO Masanori writes:
> > > At Sun, 9 Mar 2003 08:26:52 +0100,
> > > Matthias Klose wrote:
> > > >
> > > > Package: libc6-dev
> > > > Vers
GOTO Masanori writes:
> At Sun, 9 Mar 2003 08:26:52 +0100,
> Matthias Klose wrote:
> >
> > Package: libc6-dev
> > Version: 2.3.1
> > Severity: grave
> >
> > Attached is a diff of a binutils built in unstable with gcc-2.95 and
> > one built on y
Package: libc6-dev
Version: 2.3.1
Severity: grave
Attached is a diff of a binutils built in unstable with gcc-2.95 and
one built on yesterday's testing (still glibc-2.2.5). Although I
cannot prove that other build depedencies of binutils are the cause of
this failures, I start with glibc as the mo
Would it be possible to depend on the locales version, which was part
of the previous package as well?
For the moment it's not possible to install -14 until glibc -14 has
been built for these architecture. What is wrong having locales -14
and libc6 -13 installed on the system?
Matthias
GOTO Masanori writes:
> > On Sun, Jan 19, 2003 at 07:48:04PM -0800, Jeff Bailey wrote:
> > > I haven't seen mention of it on this list, so I wanted to bring it up -
> > > Bug #175526 against glibc is m68k specific.
> >
> > interesting. I am running glibc-2.3 and gcc-3.2 without much problems
>
Junichi Uekawa writes:
> > > To ensure some locales are available, I think you can use LOCPATH,
> > > and create locales locally, so that the following are available:
> > > de_DE ISO-8859-1
> > > en_US ISO-8859-1
> > > fr_FR ISO-8859-1
> > >
> > >
> > > see /usr/sbin/locale-gen on how to ge
Junichi Uekawa writes:
>
> Hi,
>
>
> To ensure some locales are available, I think you can use LOCPATH,
> and create locales locally, so that the following are available:
> de_DE ISO-8859-1
> en_US ISO-8859-1
> fr_FR ISO-8859-1
>
>
> see /usr/sbin/locale-gen on how to generate these loca
Package: glibc
Version: 2.3.1
Severity: serious
Looking at http://buildd.debian.org/build.php?arch=m68k&pkg=gcc-3.2
you'll see that beginning with
build 1:3.2.1ds5-0pre6 (latest build at Nov 14 04:53: successful)
nearly all tests of the gcc testsuite begin to fail. This is the first
build with
Package: glibc
Version: 2.3.1
Severity: serious
Looking at http://buildd.debian.org/build.php?arch=m68k&pkg=gcc-3.2
you'll see that beginning with
build 1:3.2.1ds5-0pre6 (latest build at Nov 14 04:53: successful)
nearly all tests of the gcc testsuite begin to fail. This is the first
build with
Richard Zidlicky writes:
> On Tue, Oct 29, 2002 at 06:10:57PM +0100, Yann Dirson wrote:
> > On Mon, Oct 21, 2002 at 09:43:05PM +0200, Matthias Klose wrote:
> > > Yann Dirson writes:
> > > > I have several packages (e2fsprogs, bigloo) that fail to build on
> >
Richard Zidlicky writes:
> On Tue, Oct 29, 2002 at 06:10:57PM +0100, Yann Dirson wrote:
> > On Mon, Oct 21, 2002 at 09:43:05PM +0200, Matthias Klose wrote:
> > > Yann Dirson writes:
> > > > I have several packages (e2fsprogs, bigloo) that fail to build on
> >
reassign 171778 libc6
thanks
I cannot find the report on http://bugs.debian.org/src:glibc
http://bugs.debian.org/171778 lists the maintainer as
unknown. Reassigning the report so you get aware of it ;-)
This currently breaks bootstrap of gcc-3.2 on sparc. See
http://buildd.debian.org/fetch.php?&p
reassign 171778 libc6
thanks
I cannot find the report on http://bugs.debian.org/src:glibc
http://bugs.debian.org/171778 lists the maintainer as
unknown. Reassigning the report so you get aware of it ;-)
This currently breaks bootstrap of gcc-3.2 on sparc. See
http://buildd.debian.org/fetch.php?&p
--- Begin Message ---
Matthias Klose <[EMAIL PROTECTED]> writes:
> ok, I'm forwarding this to Martin and Phil, two upstream developers
> (hopefully still ;-) listening on debian-gcc.
I would suggest that the libstdc++ autoconf test should be enhanced:
_GLIBCPP_HAVE_ACOSL should
--- Begin Message ---
Matthias Klose <[EMAIL PROTECTED]> writes:
> ok, I'm forwarding this to Martin and Phil, two upstream developers
> (hopefully still ;-) listening on debian-gcc.
I would suggest that the libstdc++ autoconf test should be enhanced:
_GLIBCPP_HAVE_ACOSL should
Debian Installer writes:
> (new) libg++2.8.1.3-glibc2.3_2.95.4-13_i386.deb optional libs
> (new) libstdc++2.10-glibc2.3_2.95.4-13_i386.deb required base
didn't see these when uploading. Do we really need new packages?
Debian Installer writes:
> (new) libg++2.8.1.3-glibc2.3_2.95.4-13_i386.deb optional libs
> (new) libstdc++2.10-glibc2.3_2.95.4-13_i386.deb required base
didn't see these when uploading. Do we really need new packages?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe"
--- Begin Message ---
Package: g77-2.95
Version: 1:2.95.4-12
Severity: normal
I have a multi-language application. It used to compile fine. Now, it
has an undefined reference when linking.
[EMAIL PROTECTED]/hello/runF77]>g77 -g -O2 -o runF772C
helloclient.o ./.libs/libClient.a -L/usr/lib/gcc-lib/
Yann Dirson writes:
> I have several packages (e2fsprogs, bigloo) that fail to build on
> m68k, apparently due to one or more gcc bug(s). Maybe that's the same
> as #146006, and #89023, but I can't tell that myself.
>
> Madkiss suggested forcing the use of gcc-3.2. But if this compiler is
> offi
Yann Dirson writes:
> I have several packages (e2fsprogs, bigloo) that fail to build on
> m68k, apparently due to one or more gcc bug(s). Maybe that's the same
> as #146006, and #89023, but I can't tell that myself.
>
> Madkiss suggested forcing the use of gcc-3.2. But if this compiler is
> offi
Jack Howarth writes:
>Now that glibc 2.3.1 is in sid, what are the plans
> for the transition to gcc 3.2.1?
we are waiting for an transition plan. My assumption was Jeff would
propose a transition plan for a _coordinated_ transition of glibc and
gcc. It seems a bit late for that :-(
> I am as
Jack Howarth writes:
>Now that glibc 2.3.1 is in sid, what are the plans
> for the transition to gcc 3.2.1?
we are waiting for an transition plan. My assumption was Jeff would
propose a transition plan for a _coordinated_ transition of glibc and
gcc. It seems a bit late for that :-(
> I am as
Jack Howarth writes:
> Hi,
>I am not filing a bug on this right now, but you should
> all be aware that any arch that wants to switch to gcc 3.2
> as its default compiler will need to address the following
> issue. The libgcc symbols starting in gcc 3.1 are now .hidden
> which means breakage of
Jack Howarth writes:
> Hi,
>I am not filing a bug on this right now, but you should
> all be aware that any arch that wants to switch to gcc 3.2
> as its default compiler will need to address the following
> issue. The libgcc symbols starting in gcc 3.1 are now .hidden
> which means breakage of
another improvement would be to read the used libgcc_s.so from the
command line, use binutils-multiarch and run it nice'd on ftp-master
or a mirror for all architectures ...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
reassign 148664 glibc
thanks
Sean Perry writes:
> Package: g++-3.1
> Version: 1:3.1-2
> Severity: normal
>
> in modern C++ the style is:
>
> #include
> std::assert(this_should_be_true);
>
> however this fails to compile under 3.1 claiming:
>
> parse error before `static_cast'
>
> my code is
reassign 148664 glibc
thanks
Sean Perry writes:
> Package: g++-3.1
> Version: 1:3.1-2
> Severity: normal
>
> in modern C++ the style is:
>
> #include
> std::assert(this_should_be_true);
>
> however this fails to compile under 3.1 claiming:
>
> parse error before `static_cast'
>
> my code is
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=68448&repeatmerged=yes
Compiling with gcc -Wall -Werror shows the very same error as with
g++. You can compile with -D_GNU_SOURCE to get the declaration from
stdio.h.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=68448&repeatmerged=yes
Compiling with gcc -Wall -Werror shows the very same error as with
g++. You can compile with -D_GNU_SOURCE to get the declaration from
stdio.h.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
Package: libc6
Version: 2.1.3-10
gcc's libstdc++-v3 in the cvs main branch is compiled with -Werror and
fails due to errors in wctype.h. There is an update in the glibc cvs
repository:
http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/libc/wctype/wctype.h.diff?r1=1.23&r2=1.24&cvsroot=glibc
Package: libc6
Version: 2.1.3-10
gcc's libstdc++-v3 in the cvs main branch is compiled with -Werror and
fails due to errors in wctype.h. There is an update in the glibc cvs
repository:
http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/libc/wctype/wctype.h.diff?r1=1.23&r2=1.24&cvsroot=glibc
--
Debian does not provide a glibc-2.0, which is installable on potato.
What about Oracle 8.1.6, is it compiled for glibc-2.1?
Greg writes:
> We need to install Oracle 8.0.5 on Potato but compiler reports
> some errors due to incompatibility glibc2.0 with glibc2.1 at
> the source level. On Slink
Debian does not provide a glibc-2.0, which is installable on potato.
What about Oracle 8.1.6, is it compiled for glibc-2.1?
Greg writes:
> We need to install Oracle 8.0.5 on Potato but compiler reports
> some errors due to incompatibility glibc2.0 with glibc2.1 at
> the source level. On Slink
reassign 57294 libc6-dev
reassign 57542 libc6-dev
thanks
--- Begin Message ---
> Regarding #54951, I think we need upstream's comments on whether or
> not the __extension__ keyword should silence this particular
> warning, glibc upstream thinks it should.
I think it should, and it appears to be f
>From the bash author:
37971 This is a locale problem. The de_DE locale gives lower case and
upper case letters the same collating weight. POSIX.2 warns that
range expressions are not portable across locales.
33822 Locale problem. Same as 37971
37971 seems to be fixed.
Package: bash
Version: 2.02.1-1.18
ii bash2.02.1-1.8 The GNU Bourne Again SHell
ii libc6 2.1.2-10 GNU C Library: Shared libraries and timezone
ii make3.78.1-1 The GNU version of the "make" utility.
This report get's a little bit unspecific. I c
Debian Bug Tracking System writes:
> Processing commands for [EMAIL PROTECTED]:
>
> > reassign 45041 libc6
> Bug#45041: pthread/throw causes abort()
> Bug reassigned from package `g++' to `libc6'.
unsure, if this belongs to libc6; I could not reproduce this problem
with gcc-2.95.2 on Solaris
Torsten Landschoff writes:
> > Traceback (innermost last):
> > File "./hello1.py", line 6, in ?
> > from _gtk import *
> > ImportError: /usr/lib/python1.5/site-packages/_gtkmodule.so: symbol __fork,
> > version GLIBC_2.0 not defined in file libpthread.so.0 with link time
> > reference
101 - 197 of 197 matches
Mail list logo
