Drool... WAS --> Re: Autoconf Version 2.14.1

Barry barry at hartford.uconn.edu
Fri Jan 5 14:40:36 PST 2001


Gerard Beekmans wrote:
> 
> > I was talking to someone (sorry, can't remenber who right now) on #LFS
> > the other day about GCC 2.95.3 (the 2.95.2 bug fix release coming up,
> > problably before 3.0 will be release) which is suppose to be compatible
> > with Glibc 2.2..
> 
> So you're saying that gcc-2.95.2 isn't compatible with glibc-2.2 ? explain
> that one please.

I think what is meant is:  Will compile correctly on...

without patches that is...and I'm reading minds here, so if I'm
completely wrong, well...oh well :)


> > as for getting Glibc 2.2 into LFS...can we just wait a little, little
> > bit?  or at least untill GCC 3.0 is release, or like in the old days
> > have a stable and development branch for the book (such as starting
> > 2.5.x for glibc 2.2/gcc 2.95.3/3.0) as much as i love bleeding to dead,
> > i also like to stay as stable as possible ;)
> 
> Perhaps your reservations regarding gcc-2.95.2 and glibc-2.2 are unwarranted.
> Perhaps they are not. I mean there's nothing wrong with being cautious about
> these things. But I don't claim to be the only person running a very stable
> system with glibc22 and gcc2952. Again what runs fine here doesn't mean it
> runs fine there (all those nice hardware intricaties). But when will you
> declare something safe enough to use? Perhaps gcc-3.0 isn't all that great as
> we hope to think, but we install gcc-3, install LFS, run a bunch of programs
> and if everything compiles fine and runs fine and daemons don't crash when
> running for a lenghty amount of time I will call such a system stable. The
> thing is, I have done all that above and more with gcc-2.95.2 with the same
> results, so from that point of view I have declared my system stable already.

yeah, but I see where he's coming from... although, I want to impliment
glibc-2.2 as soon as possible...there are some problems with 2.1.3
(security and whatnot) that are addressed in 2.2...I still have to build
a system with 2.2, which I hope to do this weekend... but it will most
likely be the next weekend, knowing my schedule...

but, 2.2 is a major release...sort of a .0 in some ways (should be
glibc-2.2.0 :> ...)

I think one thing that people miss is that the reason that we were all
having trouble compile LFS on glibc-2.1.9x and 2.2 systems was because
many of the packages haven't been rebuilt with it's little gotcha's in
mind... Most of these packages had programs that weren't built with the
strictest standardization in mind... Those are the problems I've read
about in the glibc-2.2 ... In other words, it is my feeling that we
should at least wait for some of those packages to be updated...if that
means we wait for gcc-2.95.3 ..then, so be it...it shouldn't be that
long... they've released a test version already... Then again, I said
the same thing when linux-2.4.0-test1 came out :)

(btw, I have tried building LFS from an RH7.0 box with updated glibc-2.2
rpm's... I found that the same problems exist there.  If anyone else has
had different experiences, I'm all ears...there could be problems with
rh's implimentation of 2.2 ... Red Hat make a mistake??? No - Never!!
....hehe)


> Also, the kernel says to use egcs-2.91.55 or something and not gcc-2.95.2.
> Fine, but if you can't use gcc-2.95.2 on the kernel (though I never had any
> problems) you certainly can't use gcc-3.0 to compile a kernel with. So I
> wonder if all those cautions are coming from people being over-cautious or
> there are real problems somewhere. If so I'd like to know how I can duplicate
> problems and kernel crashes and system crashes that run glibc-2.2 and was
> compiled with gcc-2.95.2

I haven't noticed any issues that I can track to glibc-2.2 and
gcc-2.95.2 (or EGCS 2.91.66)... But I can say that kernel 2.2.17 DOES
NOT compile with glibc-2.2 and gcc-2.96 ... Of course, that's rh7's
compiler... But I think that the difference here is that the gcc-2.95.x
line is code-related to later EGCS releases... In otherwords, they
shouldn't be all that different... generally speaking...

whereas the gcc-3.0 line supposedly doesn't carry the same type of
support as 2.95.2 did... so, again, major release syndrome...however,
kernel 2.2.18 DOES compile with gcc-2.96 with my tests... Appearently,
the problem was fixed...


> This isn't an attack or rant against you Jesse. I'm just thinking out loud.
> I'm just wondering; there must be some kind of benchmark to determine whether
> a glibc is stable enough to use or not. Simply having gcc-2.95.3 or gcc-3.0
> does not warrant a stable system, but if i can't see a difference in
> "stableness" when I run gcc-2.95.2 or gcc-3.0 I can't help but wonder
> 

personally, I think that the mark should be when a major release
(glibc-2.2) causes more patches to be added to code simply to make the
code compile, then we shouldn't upgrade to that version... at least,
regarding major software...

Has anyone had success building a clean gcc-2.95.2 source tree without
patching it?
How about Fileutils?

I mean, the fileutils problem was fairly major...on my system, ls didn't
print to standard output... Now, perhaps that was the only problem and
perhaps the patch fixed it, but I'll feel a little bit better once that
patch is implimented into a release...

I mean, don't get me wrong, I don't mind patching and fixing things at
all, but these base level programs are a little bit too important to
have obscure gotcha's hanging around in....

Perhaps the answer is to give an option for installing glibc-2.2 in the
book... Perhaps that's a horrible idea from a support standpoint... but
maybe it's the only way to please everyone...

-- 
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message




More information about the lfs-dev mailing list