[gentoo-releng] Re: binutils-2.14.90.0.7-r4

[gentoo-releng] Re: binutils-2.14.90.0.7-r4

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On Sun, 2004-01-18 at 13:01, Kumba wrote:
> Martin Schlemmer wrote:
> 
> > Hi
> > 
> > -r4 fixes a problem that might be security related:
> > 
> >   http://bugs.gentoo.org/show_bug.cgi?id=3703
> > 
> > Is there any pending issues for ppc,alpha,arm (still with us?) and ia64
> > to not mark it stable (basically -r3 with security fix).
> > 
> > 

> Also, should this wait still after most of the archs have released their 
> stages?  Openssl's impending stable bump I know has caused a few archs 
> to hold off on release stages.
> 

Not sure, but I would like to get gcc-3.3.2-r5 or so in as well.  Is
this still possible ?


Thanks,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-releng] Re: binutils-2.14.90.0.7-r4

[Kumba]

Martin Schlemmer wrote:

> Not sure, but I would like to get gcc-3.3.2-r5 or so in as well.  Is
> this still possible ?
> 
> 
> Thanks,

I'm building mips stages with gcc-3.3.2-r4.  -r5 will not merge on my 
Indy, although other mips users (with roughly the same Indy specs I 
have) have reported success with that version of gcc.  It keeps getting 
to a C++ source file in the final stages of gcc's bootstrap, and just 
hangs the compile up.  Doesn't hang the box, and no error messages or 
zombified processes that I can find.  Still doing research into the 
cause, I'm beginning to think I have something funny going on with the 
chroot environment.

As for sparc, we've been using the gcc33-sparc64-1.4 profile to test 
gcc-3.3.x on sparc.  Whether it is safe enough to declare stable, I'll 
let Weeve make that call.

x86, I've had no problems really.  Just we need to get the new etcat 
version out because gcc-3.3.2-r5 scans for the @guard symbols, and older 
etcat versions do not work with the newer 2.0.50 portage, causing the 
ebuild to fail (this has been my experience on sparc64 actually, but I 
would not be surprised for this to popup up elsewhere for those who 
haven't upgraded gentoolkit yet (like me)).


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


--
gentoo-releng@gentoo.org mailing list

[gentoo-releng] Re: binutils-2.14.90.0.7-r4

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

On Sun, 2004-01-18 at 13:57, Kumba wrote:
> Martin Schlemmer wrote:
> 
> > Not sure, but I would like to get gcc-3.3.2-r5 or so in as well.  Is
> > this still possible ?
> > 
> > 
> > Thanks,
> 
> I'm building mips stages with gcc-3.3.2-r4.  -r5 will not merge on my 
> Indy, although other mips users (with roughly the same Indy specs I 
> have) have reported success with that version of gcc.  It keeps getting 
> to a C++ source file in the final stages of gcc's bootstrap, and just 
> hangs the compile up.  Doesn't hang the box, and no error messages or 
> zombified processes that I can find.  Still doing research into the 
> cause, I'm beginning to think I have something funny going on with the 
> chroot environment.
> 

Even 3.3.2-r4 is fine (and was longer tested), but the point is, we need
a 3.3.x out, as there is a _lot_ of pentium4 fixes, as well as others.
I will do -r6 in a bit, maybe you can give it a bit of testing on your
indy.

> As for sparc, we've been using the gcc33-sparc64-1.4 profile to test 
> gcc-3.3.x on sparc.  Whether it is safe enough to declare stable, I'll 
> let Weeve make that call.
> 

Ill wait for him then.

> x86, I've had no problems really.  Just we need to get the new etcat 
> version out because gcc-3.3.2-r5 scans for the @guard symbols, and older 
> etcat versions do not work with the newer 2.0.50 portage, causing the 
> ebuild to fail (this has been my experience on sparc64 actually, but I 
> would not be surprised for this to popup up elsewhere for those who 
> haven't upgraded gentoolkit yet (like me)).
> 

Right, lanius (whoever), any eta on the new etcat?


Also, any definate reasons on the PPC lag in gcc versions?  They do not
even have 3.3.x in testing ....


Thanks,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-releng] Re: binutils-2.14.90.0.7-r4

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On Sun, 2004-01-18 at 14:10, Sven Blumenstein wrote:
> Kumba wrote:
> > As for sparc, we've been using the gcc33-sparc64-1.4 profile to test 
> > gcc-3.3.x on sparc.  Whether it is safe enough to declare stable, I'll 
> > let Weeve make that call.
> 
> I've been using the gcc33 profile since you released it.
> 
>  From my experience, gcc 3.3.x is save to use, BUT it can cause problems
> if you upgrade a gcc 3.2.x compiled system to gcc 3.3.x. I've heard that 
> some bigger applications like Mozilla just refuse to start which may IMO 
> be an library issue. If a user recompiles his 'world' after upgrading 
> from 3.2 to 3.3 it shouldnt be a problem. But this cannot be guaranteed.

Do we have more concrete evidence then hear-say?  I know initial 3.3's
and 3.3.1's was flaky, but 3.3.2's since -r2 or there abouts have really
behaved Ok.


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-releng] Re: binutils-2.14.90.0.7-r4

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Sun, 2004-01-18 at 14:12, Heinrich Wendel wrote:

> > > x86, I've had no problems really.  Just we need to get the new etcat
> > > version out because gcc-3.3.2-r5 scans for the @guard symbols, and older
> > > etcat versions do not work with the newer 2.0.50 portage, causing the
> > > ebuild to fail (this has been my experience on sparc64 actually, but I
> > > would not be surprised for this to popup up elsewhere for those who
> > > haven't upgraded gentoolkit yet (like me)).
> >
> > Right, lanius (whoever), any eta on the new etcat?
> 
> /me wonders why he gets this mail
> 
> I'm not in charge of gentoolkit, I think genone and karltk are.
> 

Yes, but I assumed you wrote etcat, or at least commited it.  If
you have a working version, then we can check with karltk or genone ...
If not, you could point us to the correct person?


Thanks,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: binutils-2.14.90.0.7-r4

[Luca Barbato]

Martin Schlemmer wrote:

> 
> Also, any definate reasons on the PPC lag in gcc versions?  They do not
> even have 3.3.x in testing ....
> 
Simply every gcc version past 3.2 has serious flaws in the altivec code 
generation. At best it miscompiles ad worst it segfaults.

lu

-- 
Luca Barbato
Developer
Gentoo Linux				http://www.gentoo.org/~lu_zero



--
gentoo-releng@gentoo.org mailing list