Bug#276291: wmkbd: FTBFS: g++-3.3 internal compiler error
Package: wmkbd, gcc-3.3 Version: 0.4.1-2 Severity: serious Hi, building the package wmkbd in a clean build environment (with pbuilder) on i386 results in: = [...] # Add here commands to compile the package. /usr/bin/make make[1]: Entering directory `/tmp/buildd/wmkbd-0.4.1' g++ -g -O -I/usr/openwin/include -I/usr/local/include `glib-config --cflags` `gnome-config gnomeui --cflags` `gtk-config --cflags` -DXLIB_ILLEGAL_ACCESS app.c -c -o app.o In file included from app.c:76: keysyms.c:921: internal compiler error: in tree_low_cst, at tree.c:3255 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . make[1]: *** [app.o] Error 1 make[1]: Leaving directory `/tmp/buildd/wmkbd-0.4.1' make: *** [build-stamp] Error 2 = With gcc 3.2 an 3.4, it works. Thanks for considering. bye, Roland
size gains
Within a few days you should notice immediate erection size increases 90% of males were interested in improving their sexual stamina, performance, and the size of their manhood. Are you one of the 90%? I want to let u guys know that I have seen over 1 inch in length increase since I started taking ur system. The exercises are easy too. I use them both and this is awesome. Clancy, Spokane check out the only Male Enhancement formula with a free DVD http://www.supervalueproduct.com/lg/ i am busy, no thank you, go above The effect of the electric shock conveyed by the tube was beginning to wear away, and now the buccaneer sat up, rubbed his head in a bewildered fashion and looked around him. When he saw Rob he gave a shout of rage and drew his knife, but one motion of the electric tube made him cringe and slip away to the cabin, where he remained out of danger And now the other four sat up, groaning and muttering in their outlandish speech; But they had no notion of facing Rob's tube a second time, so one by one they joined their leader in the cabin, leaving the boy undisturbed
Heighten sensation
Male enhancement is achieving your goals of becoming a better man 90% of males were interested in improving their sexual stamina, performance, and the size of their manhood. Are you one of the 90%? I cannot afford the ridiculous prescription costs since I have no health insurance and am unemployed. Your discount rates on the Internet really helped me, and your staff was very knowledgeable and helpful. I saw immediate results, and now I have regained the confidence I had when I was younger, in the bedroom. -Kenneth, Salt Lake City check out the only Male Enhancement formula with a free DVD http://www.superbitems.com/lg/ no, then link above He followed the coast line, keeping but a short distance above the earth, and after an hour's swift flight reached the city of San Francisco. His shoulders were sore and stiff from the heavy strain upon them of the previous day, and he wished more than once that he had some of his mother's household liniment to rub them with Yet so great was his delight at reaching once more his native land that all discomforts were speedily forgotten
Re: cross-gcc patches
Hello
> > 3. I'm having bad time with gcc-3.4 sparc multilib target. Current
> > debian/rules.conf contains code that changes TARGET_ALIAS from
> > sparc-linux to sparc64-linux. But this causes unwanted side-effects
> > (such as attempts to use 'sparc64-linux-as' instead of
> > 'sparc-linux-as' as assembler; that fails because there is no
> > 'sparc64-linux-as', so it falls back to 'as'; that also fails because
> > 'as' is native and can't process sparc assembler. Also, files go to
> > /usr/sparc64-linux/... instead of /usr/sparc-linux/...) If I comment
> > out TARGET_ALIAS change, buld fails with
> > In file included from ../../src/gcc/libgcc2.c:56:
> > ../../src/gcc/libgcc2.h:81: error: no data type for mode `TI'
> > ../../src/gcc/libgcc2.h:82: error: no data type for mode `TI'
> > make[4]: *** [libgcc/64/_muldi3.o] Error 1
> > Before I go deep into upstream code, I'd love to get some advice from
> > somebody who has better understanding of what that means and how
> > things work...
>
> I remember having stopped at the very same point and then found out
> about the configury done as above. CC'ed Clint and Ben.
I think I've found a fix to this.
See the attachement.
Adding a single line to gcc/config.gcc makes sparc target to build
correctly, without having to change it to sparc64.
[EMAIL PROTECTED]:~/debian/gcc/3.4/test> dpkg-architecture -qDEB_HOST_ARCH
i386
[EMAIL PROTECTED]:~/debian/gcc/3.4/test> sparc-linux-gcc-3.4 -o h hello.c
[EMAIL PROTECTED]:~/debian/gcc/3.4/test> file h
h: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for GNU/Linux 2.2.0,
dynamically linked (uses shared libs), not stripped
[EMAIL PROTECTED]:~/debian/gcc/3.4/test> sparc-linux-gcc-3.4 -m64 -o h64
hello.c
[EMAIL PROTECTED]:~/debian/gcc/3.4/test> file h64
h64: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), for GNU/Linux
2.4.18, dynamically linked (uses shared libs), not stripped
I think the attached change (that is not cross-specific) should go in
gcc-3.4 package.
With this change and the cross patch I've sent some days ago, gcc-3.4
becomes in sync with gcc-3.3 (that means, builds for all debian linux
targets, including biarch s390 and sparc).
Nikita
--- gcc-3.4/debian/patches/sparc64-build.dpatch 2004-10-04 10:54:41.0 +0400
+++ test/gcc-3.4/debian/patches/sparc64-build.dpatch 2004-10-13 18:35:05.0 +0400
@@ -37,7 +37,7 @@
diff -urNad sparc64-build.gcc-3.3.tmp/src/gcc/config.gcc sparc64-build.gcc-3.3/src/gcc/config.gcc
--- sparc64-build.gcc-3.3.tmp/src/gcc/config.gcc 2003-03-13 08:40:33.0 +
+++ sparc64-build.gcc-3.3/src/gcc/config.gcc 2003-03-13 08:48:27.0 +
-@@ -2383,8 +2383,17 @@
+@@ -2383,8 +2383,18 @@
gnu_ld=yes
;;
sparc-*-linux*) # SPARC's running GNU/Linux, libc6
@@ -49,6 +49,7 @@
+ tmake_file="t-slibgcc-elf-ver t-linux sparc/t-linux64 sparc/t-crtfm"
+ tm_file="sparc/biarch64.h ${tm_file} dbxelf.h elfos.h svr4.h sparc/sysv4.h sparc/linux64.h"
+ float_format=sparc
++ need_64bit_hwint=yes
+ fi
+ #tm_file="${tm_file} dbxelf.h elfos.h svr4.h sparc/sysv4.h sparc/linux.h"
+ #tmake_file="t-slibgcc-elf-ver t-linux sparc/t-crtfm"
--- gcc-3.4/debian/rules.defs 2004-10-06 01:00:12.0 +0400
+++ test/gcc-3.4/debian/rules.defs 2004-10-13 23:30:12.0 +0400
@@ -559,9 +559,6 @@
biarch := yes
with_lib64gcc := yes
with_lib64cxx := yes
- ifeq ($(TARGET_ALIAS),sparc-linux)
-TARGET_ALIAS := sparc64-linux
- endif
endif
# s390x build
Re: cross-gcc patches
Nikita V. Youshchenko writes: > Hello > > > > 3. I'm having bad time with gcc-3.4 sparc multilib target. Current > > > debian/rules.conf contains code that changes TARGET_ALIAS from > > > sparc-linux to sparc64-linux. But this causes unwanted side-effects > > > (such as attempts to use 'sparc64-linux-as' instead of > > > 'sparc-linux-as' as assembler; that fails because there is no > > > 'sparc64-linux-as', so it falls back to 'as'; that also fails because > > > 'as' is native and can't process sparc assembler. Also, files go to > > > /usr/sparc64-linux/... instead of /usr/sparc-linux/...) If I comment > > > out TARGET_ALIAS change, buld fails with > > > In file included from ../../src/gcc/libgcc2.c:56: > > > ../../src/gcc/libgcc2.h:81: error: no data type for mode `TI' > > > ../../src/gcc/libgcc2.h:82: error: no data type for mode `TI' > > > make[4]: *** [libgcc/64/_muldi3.o] Error 1 > > > Before I go deep into upstream code, I'd love to get some advice from > > > somebody who has better understanding of what that means and how > > > things work... > > > > I remember having stopped at the very same point and then found out > > about the configury done as above. CC'ed Clint and Ben. > > I think I've found a fix to this. > See the attachement. > Adding a single line to gcc/config.gcc makes sparc target to build > correctly, without having to change it to sparc64. thanks, please could you check if the testsuite is run for 32 and 64? Matthias
Bug#276291: wmkbd: FTBFS: g++-3.3 internal compiler error
clone 276291 -1 reassign 276291 wmkbd reassign -1 g++-3.3 severity -1 important tags -1 + upstream tags -1 + fixed-upstream retitle -1 [fixed in 3.2/3.4] ICE building wmkbd thanks there's a workaround, so it's not release critical in the gcc-3.3 package. Roland Stigge writes: > Package: wmkbd, gcc-3.3 > Version: 0.4.1-2 > Severity: serious > > Hi, > > building the package wmkbd in a clean build environment > (with pbuilder) on i386 results in: > > = > [...] > # Add here commands to compile the package. > /usr/bin/make > make[1]: Entering directory `/tmp/buildd/wmkbd-0.4.1' > g++ -g -O -I/usr/openwin/include -I/usr/local/include `glib-config --cflags` > `gnome-config gnomeui --cflags` `gtk-config --cflags` -DXLIB_ILLEGAL_ACCESS > app.c -c -o app.o > In file included from app.c:76: > keysyms.c:921: internal compiler error: in tree_low_cst, at tree.c:3255 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > For Debian GNU/Linux specific bug reporting instructions, see > . > make[1]: *** [app.o] Error 1 > make[1]: Leaving directory `/tmp/buildd/wmkbd-0.4.1' > make: *** [build-stamp] Error 2 > = > > With gcc 3.2 an 3.4, it works. > > Thanks for considering. > > bye, > Roland > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
linking with multiple versions of gcc installed
Hi, I have an older powerpc machine that is basically running Woody (stable). gcc-2.95 installed as the default compiler. glibc-2.2 installed as the C libriary. I have a newer powerpc machine that has Sarge (testing) installed on it. gcc-3.3 installed as the default compiler. glibc-2.3 installed as the C libriary. gcc-2.95 also installed. The newer machine has mounted the /home directory of the older machine via NFS. My project compiles and links fine on the old macihne using 'gcc' or 'gcc-2.95'. The new machine fails linking when using 'gcc-2.95' as the invoked command. eg. undefined references to '[EMAIL PROTECTED]' BTW, my project is using glibc-2.2.5 which is stored under configuration management. ie. None of the standard libraries or headers _SHOULD_ be used when linking or compiling etc. I am using the -nostdlib switches, etc. I think the problem is that the file /repository/glibc-2.2.5/usr/lib/libc.so has the following. GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ) I'm assuming that this causes the local system files to be referenced which is not what I want. I don't want to edit the libc.so as this file is copied to the end product filesystem. Is the correct solution to use -rpath or more likely -rpath-link in my linking commands ??? If so, could some one give me some idea of the best way to use them. Many thanks, Brendan Simon.
Bug#275655: Bug in earlier versions too; not in 3.4
I forgot to mention that earlier versions of gcc (specifically, 3.0) caused the same problem. I just installed 3.4 and everything works perfectly, so I guess this is a "<= 3.3" problem. Also, it's no longer critical that this get resolved soon since 3.4 works. =) ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
Testing sparc target (was: Re: cross-gcc patches)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Nikita V. Youshchenko writes:
> > Hello
> >
> > > > 3. I'm having bad time with gcc-3.4 sparc multilib target. Current
> > > > debian/rules.conf contains code that changes TARGET_ALIAS from
> > > > sparc-linux to sparc64-linux. But this causes unwanted
> > > > side-effects (such as attempts to use 'sparc64-linux-as' instead
> > > > of
> > > > 'sparc-linux-as' as assembler; that fails because there is no
> > > > 'sparc64-linux-as', so it falls back to 'as'; that also fails
> > > > because 'as' is native and can't process sparc assembler. Also,
> > > > files go to /usr/sparc64-linux/... instead of
> > > > /usr/sparc-linux/...) If I comment out TARGET_ALIAS change, buld
> > > > fails with
> > > > In file included from ../../src/gcc/libgcc2.c:56:
> > > > ../../src/gcc/libgcc2.h:81: error: no data type for mode `TI'
> > > > ../../src/gcc/libgcc2.h:82: error: no data type for mode `TI'
> > > > make[4]: *** [libgcc/64/_muldi3.o] Error 1
> > > > Before I go deep into upstream code, I'd love to get some advice
> > > > from somebody who has better understanding of what that means and
> > > > how things work...
> > >
> > > I remember having stopped at the very same point and then found out
> > > about the configury done as above. CC'ed Clint and Ben.
> >
> > I think I've found a fix to this.
> > See the attachement.
> > Adding a single line to gcc/config.gcc makes sparc target to build
> > correctly, without having to change it to sparc64.
>
> thanks, please could you check if the testsuite is run for 32 and 64?
Unfortunately I can't, because I don't have access to any sparc debian
systems, and cros-running testsuite doesn't seem to be possible.
Probably somebody on the list may help? I'm reattaching the fix to make it
available on list. The fix is not cross-specific, show thing to test is
that it doesn't break anything for native sparc compilers.
> one more question, if you do have access to a sparc64, please could
> you build the current gcc-3.3 for unstable?
Again, I can't help, I don't have hardware access.
Nikita
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBbgJzv3x5OskTLdsRAt0VAJ9ULMm+3IYBXZE4Y/3nh3YQ2TVS1ACgouHI
hmPH11zfalmRyehFDy4iteY=
=0hmo
-END PGP SIGNATURE-
--- gcc-3.4/debian/patches/sparc64-build.dpatch 2004-10-04 10:54:41.0 +0400
+++ test/gcc-3.4/debian/patches/sparc64-build.dpatch 2004-10-13 18:35:05.0 +0400
@@ -37,7 +37,7 @@
diff -urNad sparc64-build.gcc-3.3.tmp/src/gcc/config.gcc sparc64-build.gcc-3.3/src/gcc/config.gcc
--- sparc64-build.gcc-3.3.tmp/src/gcc/config.gcc 2003-03-13 08:40:33.0 +
+++ sparc64-build.gcc-3.3/src/gcc/config.gcc 2003-03-13 08:48:27.0 +
-@@ -2383,8 +2383,17 @@
+@@ -2383,8 +2383,18 @@
gnu_ld=yes
;;
sparc-*-linux*) # SPARC's running GNU/Linux, libc6
@@ -49,6 +49,7 @@
+ tmake_file="t-slibgcc-elf-ver t-linux sparc/t-linux64 sparc/t-crtfm"
+ tm_file="sparc/biarch64.h ${tm_file} dbxelf.h elfos.h svr4.h sparc/sysv4.h sparc/linux64.h"
+ float_format=sparc
++ need_64bit_hwint=yes
+ fi
+ #tm_file="${tm_file} dbxelf.h elfos.h svr4.h sparc/sysv4.h sparc/linux.h"
+ #tmake_file="t-slibgcc-elf-ver t-linux sparc/t-crtfm"
--- gcc-3.4/debian/rules.defs 2004-10-06 01:00:12.0 +0400
+++ test/gcc-3.4/debian/rules.defs 2004-10-13 23:30:12.0 +0400
@@ -559,9 +559,6 @@
biarch := yes
with_lib64gcc := yes
with_lib64cxx := yes
- ifeq ($(TARGET_ALIAS),sparc-linux)
-TARGET_ALIAS := sparc64-linux
- endif
endif
# s390x build
