Discussion:
GCC 4.3 not quite ready for primetime
(too old to reply)
David Kowis
2008-04-11 16:46:45 UTC
Permalink
Lots of things don't build. The kernel doesn't build for Christ's sake!
It's definitely not quite ready for the test grimoire as lots of
spells die. I can't even get through a complete rebuild.
CPIO doesn't build in gcc 4.3
the kernel doesn't build in gcc 4.3

That's like 2 out of 20. So that's like 10% of our spells won't build
on gcc 4.3. And I haven't even gotten into kde stuff yet.

I know it's the test grimoire, but this is ridiculous. This is fodder
for the devel grimoire.
Stuff in test is supposed to work for the most part. I suppose you
could define that 10% of spells failing is not the most part, but when
you can't even compile a kernel using that gcc, that's pathetic.
--
David Kowis
==================================================================
| www.ronpaul2008.com | www.sourcemage.org |
| Ron Paul for President! | SourceMage GNU/Linux |
==================================================================
Treeve Jelbert
2008-04-11 17:18:10 UTC
Permalink
Post by David Kowis
Lots of things don't build. The kernel doesn't build for Christ's sake!
It's definitely not quite ready for the test grimoire as lots of
spells die. I can't even get through a complete rebuild.
CPIO doesn't build in gcc 4.3
the kernel doesn't build in gcc 4.3
That's like 2 out of 20. So that's like 10% of our spells won't build
on gcc 4.3. And I haven't even gotten into kde stuff yet.
I have been using gcc-4.3.0 since March 14 and have compiled about 130 spells
in that time.

qt4 and all the kde4 stuff builds ok, also parts of gnome and gtk+2.

the only problem I am aware of is xine-lib
h264dsp_mmx.c: In function 'h264_h_loop_filter_luma_mmx2':
dsputil_mmx.c:636: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
dsputil_mmx.c:636: error: 'asm' operand has impossible constraints
Post by David Kowis
I know it's the test grimoire, but this is ridiculous. This is fodder
for the devel grimoire.
Stuff in test is supposed to work for the most part. I suppose you
could define that 10% of spells failing is not the most part, but when
you can't even compile a kernel using that gcc, that's pathetic.
--
Regards, Treeve
Andraž 'ruskie' Levstik
2008-04-11 17:36:37 UTC
Permalink
Post by Treeve Jelbert
Post by David Kowis
Lots of things don't build. The kernel doesn't build for Christ's
sake! It's definitely not quite ready for the test grimoire as lots of
spells die. I can't even get through a complete rebuild.
CPIO doesn't build in gcc 4.3
the kernel doesn't build in gcc 4.3
That's like 2 out of 20. So that's like 10% of our spells won't build
on gcc 4.3. And I haven't even gotten into kde stuff yet.
I have been using gcc-4.3.0 since March 14 and have compiled about 130
spells in that time.
qt4 and all the kde4 stuff builds ok, also parts of gnome and gtk+2.
the only problem I am aware of is xine-lib
dsputil_mmx.c:636: error: can't find a register in class 'GENERAL_REGS'
while reloading 'asm'
dsputil_mmx.c:636: error: 'asm' operand has impossible constraints
probably missing a register i.e. -fPIC -DPIC eats one or
-fomit-frame-pointer frees one up...
Post by Treeve Jelbert
Post by David Kowis
I know it's the test grimoire, but this is ridiculous. This is fodder
for the devel grimoire.
Stuff in test is supposed to work for the most part. I suppose you
could define that 10% of spells failing is not the most part, but when
you can't even compile a kernel using that gcc, that's pathetic.
--
Regards, Treeve
_______________________________________________
SM-Discuss mailing list
http://lists.ibiblio.org/mailman/listinfo/sm-discuss
Jaka Kranjc
2008-04-11 17:21:54 UTC
Permalink
Post by David Kowis
Lots of things don't build. The kernel doesn't build for Christ's sake!
The most recent ones do. Earlier like 2.6.24.4 need a line removed in one of
the makefiles.
--
We cannot command nature except by obeying her. --Sir Francis Bacon
Have a sourcerous day! www.sourcemage.org
Arjan Bouter
2008-04-11 22:26:07 UTC
Permalink
Post by Jaka Kranjc
Post by David Kowis
Lots of things don't build. The kernel doesn't build for Christ's sake!
The most recent ones do. Earlier like 2.6.24.4 need a line removed in one of
the makefiles.
Erm, that's not an option for some of us... If I'd use any more recent
kernel it'd mean I lose my internet connectivity... I totally agree with
David here. 10% breaking is too much, even for test.

I seem to remember, back in the old days, that changes like this were tested
separate from the test grimoire and integrated once they stabilized a
bit. Saying it doesn't matter if the kernel won't compile doesn't sound
right to me at all...

Arjan
--
+=======
Source Mage GNU/Linux developer,
http://www.sourcemage.org
Registered as user #310617 with the Linux Counter,
http://counter.li.org.
GnuPG Key 79D4B14E = 94AD 3FD1 E259 67ED 632E 2B06 CFBE 1154 79D4 B14E
+===
Eric Sandall
2008-04-11 22:53:35 UTC
Permalink
Post by Arjan Bouter
Post by Jaka Kranjc
Post by David Kowis
Lots of things don't build. The kernel doesn't build for Christ's sake!
The most recent ones do. Earlier like 2.6.24.4 need a line removed in one
of the makefiles.
Erm, that's not an option for some of us... If I'd use any more recent
kernel it'd mean I lose my internet connectivity... I totally agree with
David here. 10% breaking is too much, even for test.
I seem to remember, back in the old days, that changes like this were
tested separate from the test grimoire and integrated once they stabilized
a bit. Saying it doesn't matter if the kernel won't compile doesn't sound
right to me at all...
Arjan
I didn't say it doesn't matter, just that (for me) it worked when I tested it
(but only on x86_64, as I found out after checking again). There are fixes,
they are simple, they just need to be applied.

Also note that this *has* been available for testing in the devel-gcc branch
for almost a month (March 17) and I only pushed it to test after posting,
repeatedly (basically a whole thread with just me talking and one comment by
Jaka), my progress with it and that I had tested 600+ spells with my changes.
I even went out of my way and tested all of the mozilla packages, and fixed
most (not all were easily fixable), even though I only use one of them.

Don't say we didn't ask for testing nor provide the means to do so. ;)

-sandalle
--
Eric Sandall | Source Mage GNU/Linux Developer
***@sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285
Eric Sandall
2008-04-11 17:30:36 UTC
Permalink
Post by David Kowis
Lots of things don't build. The kernel doesn't build for Christ's sake!
It's definitely not quite ready for the test grimoire as lots of
spells die. I can't even get through a complete rebuild.
CPIO doesn't build in gcc 4.3
the kernel doesn't build in gcc 4.3
That's like 2 out of 20. So that's like 10% of our spells won't build
on gcc 4.3. And I haven't even gotten into kde stuff yet.
I know it's the test grimoire, but this is ridiculous. This is fodder
for the devel grimoire.
Stuff in test is supposed to work for the most part. I suppose you
could define that 10% of spells failing is not the most part, but when
you can't even compile a kernel using that gcc, that's pathetic.
Use a newer kernel. :)

As for spell failures...the spells which fail for you are working on three of
my boxes (two x86 and one x86_64). The only major issue I've run into is
gnupg, which I'm testing now (thanks to Ladislav's hint) and will try to find
a good fix, otherwise I'll just revert the latest curl.

I have 600+ spells compiling fine.

-sandalle
--
Eric Sandall | Source Mage GNU/Linux Developer
***@sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285
David Kowis
2008-04-11 19:16:50 UTC
Permalink
Post by Eric Sandall
Use a newer kernel. :)
so 2.6.24.4 isn't new enough? it's the latest in test...
Post by Eric Sandall
As for spell failures...the spells which fail for you are working on three of
my boxes (two x86 and one x86_64). The only major issue I've run into is
gnupg, which I'm testing now (thanks to Ladislav's hint) and will try to find
a good fix, otherwise I'll just revert the latest curl.
Well on a new install, switching to test from whatever comes on the
latest devel iso, causes it to fail a sorcery rebuild.
Post by Eric Sandall
I have 600+ spells compiling fine.
We must have some kind of creep. Are you testing from test or from
stable? Do we want to care about things like this? I mean, we support
from 4.2.3 to 4.3.0 but not from 4.1 to 4.3 .

Just food for thought, because my upgrade path went terribly, but
yours is working fine. Our paths must be different somehow.
--
David Kowis
==================================================================
| www.ronpaul2008.com | www.sourcemage.org |
| Ron Paul for President! | SourceMage GNU/Linux |
==================================================================
Eric Sandall
2008-04-11 22:24:29 UTC
Permalink
Post by David Kowis
Post by Eric Sandall
Use a newer kernel. :)
so 2.6.24.4 isn't new enough? it's the latest in test...
Hrm...I have 2.6.24.4 compiling on my x86_64 box, but on three x86 boxes, it
fails with:
...
LD .tmp_vmlinux1
kernel/built-in.o: In function `getnstimeofday':
(.text+0x1ae2b): undefined reference to `__umoddi3'
kernel/built-in.o: In function `getnstimeofday':
(.text+0x1ae4e): undefined reference to `__udivdi3'
kernel/built-in.o: In function `do_gettimeofday':
(.text+0x1af60): undefined reference to `__udivdi3'
kernel/built-in.o: In function `do_gettimeofday':
(.text+0x1af7e): undefined reference to `__umoddi3'
kernel/built-in.o: In function `timekeeping_resume':
timekeeping.c:(.text+0x1b1f6): undefined reference to `__umoddi3'
timekeeping.c:(.text+0x1b216): undefined reference to `__udivdi3'
kernel/built-in.o: In function `update_wall_time':
(.text+0x1b520): undefined reference to `__umoddi3'
kernel/built-in.o: In function `update_wall_time':
(.text+0x1b540): undefined reference to `__udivdi3'
kernel/built-in.o: In function `update_wall_time':
(.text+0x1b9a8): undefined reference to `__umoddi3'
kernel/built-in.o: In function `update_wall_time':
(.text+0x1b9c8): undefined reference to `__udivdi3'
make: *** [.tmp_vmlinux1] Error 1
Post by David Kowis
Post by Eric Sandall
As for spell failures...the spells which fail for you are working on
three of my boxes (two x86 and one x86_64). The only major issue I've run
into is gnupg, which I'm testing now (thanks to Ladislav's hint) and will
try to find a good fix, otherwise I'll just revert the latest curl.
Well on a new install, switching to test from whatever comes on the
latest devel iso, causes it to fail a sorcery rebuild.
I didn't try that, but rather from one test to another test grimoire.
Post by David Kowis
Post by Eric Sandall
I have 600+ spells compiling fine.
We must have some kind of creep. Are you testing from test or from
stable? Do we want to care about things like this? I mean, we support
from 4.2.3 to 4.3.0 but not from 4.1 to 4.3 .
Just food for thought, because my upgrade path went terribly, but
yours is working fine. Our paths must be different somehow.
I would like to support stable -> test, since test will eventually become a
stable release and not everyone updates every stable release.

Do you recall what errors you were getting? Did gcc, g++, and glibc all
compile fine for you?

-sandalle
--
Eric Sandall | Source Mage GNU/Linux Developer
***@sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285
Eric Sandall
2008-04-11 22:26:41 UTC
Permalink
<snip>
Post by Eric Sandall
Post by David Kowis
We must have some kind of creep. Are you testing from test or from
stable? Do we want to care about things like this? I mean, we support
from 4.2.3 to 4.3.0 but not from 4.1 to 4.3 .
Just food for thought, because my upgrade path went terribly, but
yours is working fine. Our paths must be different somehow.
I would like to support stable -> test, since test will eventually become a
stable release and not everyone updates every stable release.
Do you recall what errors you were getting? Did gcc, g++, and glibc all
compile fine for you?
Are you using stable-0.18? stable-0.19 has GCC 4.2.3. I can start working on
fixing spells for stable-0.18 -> test+GCC 4.3 if that's so.

-sandalle
--
Eric Sandall | Source Mage GNU/Linux Developer
***@sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285
David Kowis
2008-04-12 04:21:20 UTC
Permalink
Post by Eric Sandall
<snip>
Post by Eric Sandall
Post by David Kowis
We must have some kind of creep. Are you testing from test or from
stable? Do we want to care about things like this? I mean, we support
from 4.2.3 to 4.3.0 but not from 4.1 to 4.3 .
Just food for thought, because my upgrade path went terribly, but
yours is working fine. Our paths must be different somehow.
I would like to support stable -> test, since test will eventually become a
stable release and not everyone updates every stable release.
Do you recall what errors you were getting? Did gcc, g++, and glibc all
compile fine for you?
Are you using stable-0.18? stable-0.19 has GCC 4.2.3. I can start working on
fixing spells for stable-0.18 -> test+GCC 4.3 if that's so.
I'm in winders right now, gcc and g++ compiled fine. I'll check the
activity log when I get it back, I had whatever gcc was installed off
the latest devel ISO, if you're impatient ;)

Loading...