On Sat, Feb 16, 2002 at 11:57:41PM +0100, Peter Koellner wrote:
> On Sat, 16 Feb 2002, Ben Collins wrote:
>
> > >
> > > well, and then take the fact that dpkg gcc 2.95.4 is derived from the
> > > original
> > > sources of gcc 2.95.2..
> > >
> >
> > I have no idea where you get this from. The comp
On Sunday 17 February 2002 02:09, you wrote:
> On Sunday 17 February 2002 01:49, Daniel Jacobowitz wrote:
> > Does this still happen if you compile the C++ with g++?
>
> Yes, it does.. I forgot to include a backtrace in my the report, it is:
>
> 0x00010750 in __static_initialization_and_destruction
On Sunday 17 February 2002 01:49, Daniel Jacobowitz wrote:
>
> Does this still happen if you compile the C++ with g++?
Yes, it does.. I forgot to include a backtrace in my the report, it is:
0x00010750 in __static_initialization_and_destruction_0(int, int) ()
(gdb) bt
#0 0x00010750 in __static_i
On Sun, Feb 17, 2002 at 06:37:05AM +0100, Arjen Hommersom wrote:
> Package: gcc
> Version: 3.0.3-1
>
> This script:
>
> #!/bin/sh
>
> cat > /tmp/test.cc << EOF
> #include
>
> int main(void)
> {
>return 0;
> }
> EOF
> cd /tmp
> gcc -o /tmp/test -fPIC /tmp/test.cc -lstdc++
Daniel Sjölie <[EMAIL PROTECTED]> writes:
> Not sure, not my code, but would gdb say this if it wasn't true?
> > > (gdb) print _ptr
> > > $5 = (Object *) 0x808f170
It certainly would. gdb just reports what the compiler (and thus the
code) claims to be the static type of the pointer.
Regards,
Mar
On 2002-02-16 23:01:21, Martin v. Loewis wrote:
> Daniel SjÂölie <[EMAIL PROTECTED]> writes:
>
> > 0x400a9c59 in osgDB::ReaderWriter::ReadResult::getNode() (this=0xb2a0)
> > at /home/source/osg/cvs/include/osgDB/ReaderWriter:64
> > 64 osg::Node* getNode() { return
>
Package: gcc
Version: 3.0.3-1
This script:
#!/bin/sh
cat > /tmp/test.cc << EOF
#include
int main(void)
{
return 0;
}
EOF
cd /tmp
gcc -o /tmp/test -fPIC /tmp/test.cc -lstdc++
/tmp/test
rm -rf /tmp/test.cc
rm -rf /tmp/test
results in a segmentation fault.
This is in Debian GNU/
On Sun, Feb 17, 2002 at 12:29:06AM +0100, Peter Koellner wrote:
> On Sat, 16 Feb 2002, Matthias Klose wrote:
>
> > It's unfortunate, that 2.95.x development got stuck somewhere.
There's a limited amount of manpower. If you want to contribute to the 2.95
branch, feel free. The release manager is
On Sat, 16 Feb 2002, Matthias Klose wrote:
> that's some kind of misinformation. 2.95.4 is derived from 2.95.3,
> following the gcc-2_95-branch on CVS.
ok, accepted, see my previous posting. i really have nothing against
2.95.4 as such...
> It's unfortunate, that 2.95.x development got stuck som
On Sat, 16 Feb 2002, Ben Collins wrote:
> >
> > well, and then take the fact that dpkg gcc 2.95.4 is derived from the
> > original
> > sources of gcc 2.95.2..
> >
>
> I have no idea where you get this from. The compiler core is straight
> from GCC's 2.95.4, plus some CVS patches. Yeah, maybe part
Peter Koellner writes:
> well, and then take the fact that dpkg gcc 2.95.4 is derived from
> the original sources of gcc 2.95.2..
that's some kind of misinformation. 2.95.4 is derived from 2.95.3,
following the gcc-2_95-branch on CVS.
Documentation/Changes reads:
The recommended compiler for t
On Sat, Feb 16, 2002 at 11:11:53PM +0100, Peter Koellner wrote:
> well, and then take the fact that dpkg gcc 2.95.4 is derived from the
> original sources of gcc 2.95.2..
That part is just not true. It's a branch snapshot from after the
release of 2.95.3.
--
Daniel Jacobowitz
>
> well, and then take the fact that dpkg gcc 2.95.4 is derived from the original
> sources of gcc 2.95.2..
>
I have no idea where you get this from. The compiler core is straight
from GCC's 2.95.4, plus some CVS patches. Yeah, maybe parts like libg++
are still the same version as from 2.95.2,
On 16 Feb 2002, Martin v. Loewis wrote:
> Now, there are unfortunately very comlex interactions between the
> compiler version and specific constructs used in the Linux kernel that
> may cause miscompilations. However, without investigating the specific
> case, nobody can give a recommendation whi
Daniel SjÂÃlie <[EMAIL PROTECTED]> writes:
> 0x400a9c59 in osgDB::ReaderWriter::ReadResult::getNode() (this=0xb2a0)
> at /home/source/osg/cvs/include/osgDB/ReaderWriter:64
> 64 osg::Node* getNode() { return
> dynamic_cast(_object.get()); }
> (gdb) s
>
> Program recei
Peter Koellner <[EMAIL PROTECTED]> writes:
> sure. maybe i did not made quite clear, that i did not expect help with
> the compilation error at all, but was asking for the current method to set
> up a debian system for kernel development tasks, so that i don't get
> a response of "use the right co
Installing:
cpp-3.0_3.0.4-0pre020210_arm.deb
to pool/main/g/gcc-3.0/cpp-3.0_3.0.4-0pre020210_arm.deb
fixincludes_3.0.4-0pre020210_arm.deb
to pool/main/g/gcc-3.0/fixincludes_3.0.4-0pre020210_arm.deb
g++-3.0_3.0.4-0pre020210_arm.deb
to pool/main/g/gcc-3.0/g++-3.0_3.0.4-0pre020210_arm.deb
g77-3
Package: g++-3.0
Version: 1:3.0.4-0pre020210
Severity: important
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux abyss 2.4.16 #1 Tue Nov 27 04:00:11 CET 2001 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages g++-3.0 depends on:
ii gcc-3.0 1:3.0.4-0pr
On Sat, 16 Feb 2002, Ben Collins wrote:
> feasibly give you an answer because there are hundreds of ways that
> there could be a problem with the compiler in that case. Our best effort
> would simply be to point you to the list of several hundred bugs and let
> you peruse them to see if they relat
On Sat, Feb 16, 2002 at 05:56:22PM +0100, Peter Koellner wrote:
> On Sat, 16 Feb 2002, Ben Collins wrote:
>
> > This is definitely a source bug in i810_audio.c. In 2.5.x somewhere, the
> > remap_page_range() function changed its expected arguments. Seems this
> > driver wasn't updated.
>
> yes, i
On Sat, 16 Feb 2002, Ben Collins wrote:
> This is definitely a source bug in i810_audio.c. In 2.5.x somewhere, the
> remap_page_range() function changed its expected arguments. Seems this
> driver wasn't updated.
yes, i know. the whole point was this: for me as a developer, the first
check for in
On Sat, Feb 16, 2002 at 05:40:01PM +0100, Peter Koellner wrote:
> On Sat, 16 Feb 2002, Ben Collins wrote:
>
> > How about telling us the error? We use out 2.95.4 compiler to create out
> > own images for Debian kernels. So if you want a sane answer, instead of
> > some rambling guesses, supply the
On Sat, 16 Feb 2002, Ben Collins wrote:
> How about telling us the error? We use out 2.95.4 compiler to create out
> own images for Debian kernels. So if you want a sane answer, instead of
> some rambling guesses, supply the damn error.
well, as i said... there is no difference in behaviour betwe
On Sat, Feb 16, 2002 at 05:17:53PM +0100, Peter Koellner wrote:
> On Sat, 16 Feb 2002, Ben Collins wrote:
>
> > You'd probably get a better response if you actually explain your
> > compile error.
>
> well, it is known that kernel source is a bit picky about compilers and
> kernel developers don'
On Sat, 16 Feb 2002, Ben Collins wrote:
> You'd probably get a better response if you actually explain your
> compile error.
well, it is known that kernel source is a bit picky about compilers and
kernel developers don't want to be bothered with bug reports that might
be caused by using a differe
On Sat, Feb 16, 2002 at 04:07:38PM +0100, Peter Koellner wrote:
> hi!
>
> i have run into some compilation problems with the 2.5.5 development kernel
> and before sending an irrelevant bug report to the kernel code maintainer
> i would like to make sure i do use the right compiler version.
> kerne
hi!
i have run into some compilation problems with the 2.5.5 development kernel
and before sending an irrelevant bug report to the kernel code maintainer
i would like to make sure i do use the right compiler version.
kernel compilations seems to require gcc 2.95.3, but the debian package
2.95.4-9
On Fri, 15 Feb 2002, Christopher C. Chimelis wrote:
> I don't know much about the qlogicisp driver since I don't have one (I
> stick to symbios chips on my alphas since I'm VERY familiar with them from
> my API days). Is that line the memcpy line? If so, what are the details
> on the panic? Als
28 matches
Mail list logo
