Hi !
Is 2.2.20 supposed to works when compiled with gcc-3.0.2 ?
It boots, but I have some missing symbols while loading some modules.
The same config works fine with gcc-2.95.4
-------
Regards
Jean-Luc
> Is 2.2.20 supposed to works when compiled with gcc-3.0.2 ?
> It boots, but I have some missing symbols while loading some modules.
> The same config works fine with gcc-2.95.4
Use egcs-1.1.2 or gcc 2.95.[3,4]
gcc 3.0 is not supported in 2.2, and there are no plans to do so
On Sun Nov 04 2001, f5ibh wrote:
> Is 2.2.20 supposed to works when compiled with gcc-3.0.2 ?
No, use gcc 2.95.x
> It boots, but I have some missing symbols while loading some modules.
> The same config works fine with gcc-2.95.4
gcc-2.95.4 does not exist! The latest stable release is 2.95.3.
--
# Heinz Diehl, 68259 Mannheim, Germany
On Sun, 4 Nov 2001, Heinz Diehl wrote:
> > It boots, but I have some missing symbols while loading some modules.
> > The same config works fine with gcc-2.95.4
>
> gcc-2.95.4 does not exist! The latest stable release is 2.95.3.
Ah, it does exist. You have to check it out from CVS from the GCC people.
I've no doubt a release will be made soon.
--
Come the revolution, humourless gits'll be first up against the wall.
http://www.tahallah.demon.co.uk
Hi.
>>>It boots, but I have some missing symbols while loading some modules.
>>>The same config works fine with gcc-2.95.4
>>>
>>gcc-2.95.4 does not exist! The latest stable release is 2.95.3.
>>
>
> Ah, it does exist. You have to check it out from CVS from the GCC people.
> I've no doubt a release will be made soon.
That's what's called a not released product.
2.95.4 might or might not be released shortly.
It is not the final 2.95.4 that is in the CVS.
Another word for it might be BETA...
// Stefan
> >>gcc-2.95.4 does not exist! The latest stable release is 2.95.3.
> > Ah, it does exist. You have to check it out from CVS from the GCC people.
> > I've no doubt a release will be made soon.
>
> That's what's called a not released product.
>
> 2.95.4 might or might not be released shortly.
>
> It is not the final 2.95.4 that is in the CVS.
>
> Another word for it might be BETA...
We're being extremely conservative about patches applied to the 2.95.x
CVS branch. It is intended always to be release-quality material.
I'm not aware of any plans for an official 2.95.4 anytime soon.
However, system integrators often track that CVS branch with their GCC
packages. For instance:
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011006 (Debian prerelease)
zw
On Mon, 5 Nov 2001, Stefan Smietanowski wrote:
> Another word for it might be BETA...
Nope, it's release quality material.
--
Love like you've never been hurt. Dance like there's noone there.
http://www.tahallah.demon.co.uk
I've posted previously about my ongoing pains with a diskless cluster of
dual cpu serverworks boards that use on-board Intel eepro100 chips.
Basically the nodes randomly reboot themselves. See previous posts by me
for more thorough description.
After reading some more of the posts recently regarding the eepro/100 on
board nics, and the various drivers available, I think that my symptoms
are possibly consistent with the problem where the card flakes out. We
are using the eepro100.c compiled statically.
I'd like to try the e100 module from Intel, but I can't get it to work
with nfsroot.
The Intel e100 driver is only available as a module.
IP autoconfig (which does not appear to be available as a module) attempts
to set the address before the module is loaded and the card is detected,
thus by the time the module is loaded from my initrd the system has
already given up on ip autoconfig and thus cannot mount its nfsroot
filesystem.
Is there a way to make the intel driver static? or perhaps to make ip
autoconfig a module, or to configure the network in another way in
combination with nfsroot?
thanks,
-ryan
--
Ryan Sweet <[email protected]>
Atos Origin Engineering Services
http://www.aoes.nl
>>>>gcc-2.95.4 does not exist! The latest stable release is 2.95.3.
>>>>
>>>Ah, it does exist. You have to check it out from CVS from the GCC people.
>>>I've no doubt a release will be made soon.
>>>
>>That's what's called a not released product.
>>
>>2.95.4 might or might not be released shortly.
>>
>>It is not the final 2.95.4 that is in the CVS.
>>
>>Another word for it might be BETA...
>>
>
> We're being extremely conservative about patches applied to the 2.95.x
> CVS branch. It is intended always to be release-quality material.
I am aware of this.
> I'm not aware of any plans for an official 2.95.4 anytime soon.
> However, system integrators often track that CVS branch with their GCC
> packages. For instance:
>
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> gcc version 2.95.4 20011006 (Debian prerelease)
I know how it's done, it's just that in my eyes a stable release is the
one where you know there's only 1 .... A 2.95.4 package built on
different days (from CVS) will differ. A 2.95.4 package built on
different ways from a .tar.gz marked as 'release' will not differ.
For instance chasing a kernel bug is difficult when 1 person might use 1
version of a compiler and another uses a different version when both
says 2.95.4, no matter how miniscule the difference.
// Stefan
Hi.
>>Another word for it might be BETA...
>>
>
> Nope, it's release quality material.
When something really is release quality material it is released.
It might be good, I'm not arguing, but if they won't release it yet then
it's probably good, not totally release quality.
// Stefan
On Mon, Nov 05, 2001 at 02:09:09PM +0100, Stefan Smietanowski wrote:
>
> I know how it's done, it's just that in my eyes a stable release is the
> one where you know there's only 1 .... A 2.95.4 package built on
> different days (from CVS) will differ. A 2.95.4 package built on
> different ways from a .tar.gz marked as 'release' will not differ.
>
> For instance chasing a kernel bug is difficult when 1 person might use 1
> version of a compiler and another uses a different version when both
> says 2.95.4, no matter how miniscule the difference.
Since patches are being applied to the 2.95 branch at a rate of about
one a month, I think the date stamp in the version number should be
quite sufficient to avoid any problems along these lines.
zw
Hi!
>>I know how it's done, it's just that in my eyes a stable release is the
>>one where you know there's only 1 .... A 2.95.4 package built on
>>different days (from CVS) will differ. A 2.95.4 package built on
>>different ways from a .tar.gz marked as 'release' will not differ.
>>
>>For instance chasing a kernel bug is difficult when 1 person might use 1
>>version of a compiler and another uses a different version when both
>>says 2.95.4, no matter how miniscule the difference.
>>
>
> Since patches are being applied to the 2.95 branch at a rate of about
> one a month, I think the date stamp in the version number should be
> quite sufficient to avoid any problems along these lines.
If it's tested and rock stable, why isn't it released?
// Stefan
On Mon, Nov 05, 2001 at 10:03:21PM +0100, Stefan Smietanowski wrote:
> Hi!
>
>
> >>I know how it's done, it's just that in my eyes a stable release is the
> >>one where you know there's only 1 .... A 2.95.4 package built on
> >>different days (from CVS) will differ. A 2.95.4 package built on
> >>different ways from a .tar.gz marked as 'release' will not differ.
> >>
> >>For instance chasing a kernel bug is difficult when 1 person might use 1
> >>version of a compiler and another uses a different version when both
> >>says 2.95.4, no matter how miniscule the difference.
> >>
> >
> >Since patches are being applied to the 2.95 branch at a rate of about
> >one a month, I think the date stamp in the version number should be
> >quite sufficient to avoid any problems along these lines.
>
> If it's tested and rock stable, why isn't it released?
It would be silly to generate a new 2.95.x point release every time we
fix a bug - most of them are minor, affect very few people, and the
fixes will get picked up by the distros anyway.
There probably will be a 2.95.4 official release at some point,
but again I'm not aware of any current plans.
zw