I’m sorry if this is the wrong place to post this, but I’m still trying to
figure everything out.
Am I correct in concluding that this bug doesn’t affect packages compiled for
Bookworm on AMD64? What about packages on AMD64 (like libpcre2-32-0) with
32-bit runtimes/versions/ABIs or packages (li
es
too and would probably show up if the control files where regularly
regenerated on non-x86 hosts.
Regards,
Alex.
Package: gcc-4.4-base
Version: 4.4.4-7
Severity: critical
Tags: squeeze
Justification: causes serious data loss
When using one of the printf functions, guint64 variables cause the following
value to be incorrectly displyed.
The following code illustrates this:
#include
#include
int main( argv,
s the return value is not used.
Ashamed.
:) Alex
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: gcj-4.2
Version: 4.2.2-3
Severity: important
Since gcc 4.2.0, gcj incorporated native support for linking to a static
libgcj (via the -static-libgcj option, as explained in
http://gcc.gnu.org/wiki/Statically%20linking%20libgcj ).
The thing is that the static libgcj is nowhere in debian.
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Alex Romosan <[EMAIL PROTECTED]> [2007-04-19 17:52]:
>> compiling with -gstabs+ and -O2 still causes g++ to crash.
>
> Really? With g++-4.1 4.1.1-21, or which version do you have?
yes. this is on amd64 with g++ 4.1.1-
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Alex Romosan <[EMAIL PROTECTED]> [2006-11-02 09:54]:
>> if i try to compile vamos from cvs i get:
> ...
>> the code seems to be okay, and compiling with -O0 works so it's probably
>> gcc's faul
instructions,
see .
make[2]: *** [andmaybepostlist.lo] Error 1
make[2]: Leaving directory `/usr/local/xapian-core-0.9.6/matcher'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/xapian-core-0.9.6'
make: *** [all] Error 2
building the object with -O1 fixes the
.1 i
get:
In destructor 'virtual A::~A()':
17: error: no suitable 'operator delete' for 'A'
In function 'int main()':
24: error: no suitable 'operator delete' for 'A'
25: error: no suitable 'operator delete' for 'A'
27:
Matthias Klose <[EMAIL PROTECTED]> writes:
> Alex Romosan writes:
>> Package: libg2c0-dev
>> Version: 1:3.4.4-7
>> Severity: minor
>>
>> i am not really sure why /usr/lib64 is includede in a package for a 32
>> bit architecture (i386 in this ca
Package: libg2c0-dev
Version: 1:3.4.4-7
Severity: minor
i am not really sure why /usr/lib64 is includede in a package for a 32
bit architecture (i386 in this case). please move them to their own
package.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy:
Looking at http://gcc.gnu.org/PR18591 it seems that "upstream" have fixed
the issue (arround 2005-06-05)
Alex Owen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Here's what I know now :
_ gcc will get the 2.8.1 dir in /usr/lib/gcc-lib/i486-linux/, even if 3.3.5
is present. However it fails with the first one
_ gnat needs 2.8.1, it fails without it...
Now where it gets even weirder, if gnat is uninstalled (or if the 2.8.1 dir
is renamed to something else
type -a gcc gives /usr/bin/gcc
As for gnat, did a 'dpkg -L gnat|grep gcc' and the only entry that I found
(except the .../i486-linux/2.8.1 dir) was /usr/bin/gnatgcc
_
Express yourself instantly with MSN Messenger! Download today it's
Here is the output as requested :
lrwxrwxrwx 1 root root16 2005-01-10 22:55 /usr/bin/gcc ->
/usr/bin/gcc-3.3
-rwxr-xr-x 1 root root 85196 2005-01-08 15:55 /usr/bin/gcc-3.3
-rwxr-xr-x 1 root root 61000 2004-09-18 19:08 /usr/bin/gnatgcc
The thing is that I have tried to find a solution and f
Oh, and I tried to remove (apt-get remove --purge gnat), it didn't change
anything. Maybe there's another package to remove, I don't know, but I
mention it in case it might seem usefull...
_
FREE pop-up blocking with the new MSN To
Yes I do, is it related to that ?
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subjec
Subject: gcc-3.3: gcc always report segfault
Package: gcc-3.3
Version: 1:3.3.5-6
Severity: normal
Hello,
while trying to compile a module for my kernel, I got a segmentation
fault
from gcc. After having searched to find out what was the cause, I
realized
that gcc was acting weird. When typing 'gc
s (the quick and dirty way
is to make distclean and recompile everything). the gcc files have
moved to /usr/lib/gcc-lib/i486-linux/3.3.5 since this is the version
you are using. this is not a gcc bug.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance
it turns out the bug is in libstdc++5-3.3-dev.
/usr/lib/gcc-lib/i486-linux/3.3.4/libstdc++.so incorrectly points to
../../../i386-linux/libstdc++.so.5 instead of ../../../libstdc++.so.5
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it
Package: libstdc++6-dev
Version: 3.4.1-2
Severity: important
/usr/lib/gcc/i486-linux/3.4.1/libstdc++.so points to a non-existent
../../../i386-linux/libstdc++.so.6. it should point to
../../../libstdc++.so.6
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT poli
Package: g++-3.3
Version: 1:3.3.4-4
Severity: important
trying to compile the nurbs++ library from cvs (available by anonymous
cvs from :pserver:[EMAIL PROTECTED]:/cvsroot/libnurbs) i
get:
/usr/bin/ld: .libs/libmatrix.so.1.0.0: undefined versioned symbol name
std::time_put_w@@GLIBCPP_3.2
/usr/bin
ions, see
.
i've discovered by trial and error that if i remove -funroll-loops
from the list of options than the compilation works.
hope this helps.
--alex--
gcc-test.tar.gz
Description: files to be compiled
--
| I believe the moment is at hand when, by a paranoiac and active |
| advanc
Matthias Klose <[EMAIL PROTECTED]> writes:
> Alex Romosan writes:
>> Matthias Klose <[EMAIL PROTECTED]> writes:
>>
>> > gcc -c -O3 -mcpu=pentiumpro -fomit-frame-pointer -falign-functions=4
>> > -falign-loops=4 -falign-jumps=4 -mpreferred-stac
lib from cvs with the current compiler.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
, i tried adding back -frename-registers
when using -O2 and the compiler crashed again. so i think the problem
is with the optimizations done when enabling -frename-registers. hope
this helps.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind
Matthias Klose wrote:
anyway, please build the
gcc-3.4 package from experimental for a comparision.
Alex Perry wrote:
> Good idea. In progress.
> I note in passing that some of the patches have rejects.
$ grep unexpected gcc-3.4.log
# of unexpected failures8
# of unexpected suc
Matthias Klose wrote:
Alex Perry writes:
Attached message is my most recent posting to the AMD64 porting
list. GCC appears to build successfully, but checks fail as shown
in the attachment.
"fails"? the test results look pretty good.
I was assuming that this aspect of the test
build any other software,
such as SSL, that doesn't need heavy access to the floating point support.
I have a pure64 environment and a pure32 environment only ... at this time.
I'm in the process of setting up a cross toolchain for pure64 that runs
on pure32.
Thanks, Alex.
--- Begin M
bug as "stupid" and sorry for the noise.
Regards,
Alex
nd 1
/tmp/cc3VnwUh.s:293: Error: invalid character '=' in operand 1
/tmp/cc3VnwUh.s:303: Error: invalid character '=' in operand 1
[type2:lttk]$
Thanks,
Alex Tsariounov
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux type2 2.4.21-4-68
confused so it's hard to be
clear.
I have one further question: Are .rpo files from different versions of gcc
compatible? I have bizarre results (as you'd expect) from using left-over
.rpo files from gcc-3.2, when linking and recompiling with gcc-3.3.
Thanks,
Alex Tibbles
s play because that's what we do here
at lbl) because gcc is broken.
anyway, you guys have fun.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systema
years). i find it harder to deal with breaking _essential_
packages like gcc. got it?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
e debian developers only. i
filed a bug against gcc in debian not gcc in general. please accept my
apologies.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states)
all alpha machines so it looks
like you _do_ have an alpha available.
myabe in the future you should test the compiler on those machines as
well before inflicting it on everybody else (not everybody uses i386).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| a
Matthias Klose <[EMAIL PROTECTED]> writes:
> Alex Romosan writes:
>> Matthias Klose <[EMAIL PROTECTED]> writes:
>>
>> > Alex Romosan writes:
>> >> Matthias Klose <[EMAIL PROTECTED]> writes:
>> >>
>> >> > please
Matthias Klose <[EMAIL PROTECTED]> writes:
> Alex Romosan writes:
>> Matthias Klose <[EMAIL PROTECTED]> writes:
>>
>> > please the bug reporting instructions: "with preprocessed source if
>> > appropriate".
>>
>> we are talki
Package: libstdc++5
Version: 1:3.3-0pre6
Severity: important
after upgrading libstdc++5, now i get:
symbol _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E,
version GLIBCPP_3.2 not defined in file libstdc++.so.5 with link time
reference
this is for every c++ program.
on a re
dc++5-dev 3.2.3-0pre9The GNU Standard C++ Library v3 (development
ii g++-3.23.2.3-0pre9The GNU C++ compiler
is this safe?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| autom
: ld returned 1 exit status
Works w/o optimization or w/ gcc-2.96
--
Alex Williamson Linux Development Lab
[EMAIL PROTECTED] Hewlett Packard
970-898-9173 Fort Collins, CO#include
#include
41 matches
Mail list logo
