|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] RedHat 7.1 glibc2.1 Backward compat - revisited
|
On Fri, May 25, 2001 at 05:15:18PM -0400, Greg Lopp wrote:
> On Fri, May 25, 2001 at 10:09:14AM -0400, Mental wrote:
> > All the fuss is about changes in gcc. Gcc does some asm stuff differnetly
> > than it used to. Compilers and kernels are pretty complex. The lkml faq
> > explains why there's a recomended compiler for the kernel source tree.
> >
> > If you're interested in the "binary incompatible" nonsense, read up on
> > assembler languages.
> Yea, uh, that's how I earn a living. I'm currently on the tail end of
> a project to migrate some embedded code from one toolset (Watcom 10a,
> MSC and MASM in DOS6 ... all circa 1993) to another (someone decided
> on CAD/ul. Nobody else would recognize far pointers...). I regularly
> wrestle with endianness and stack frames. I know what these kinds of
> problems are. I just want to know what this problem is specificaly.
>
Then I'd suggest looking at the gcc/lkml list archives. It was never
discussed here, its about a year old. Its definitely been dealt with.
Being as it never affected me, I never paid it more than passing notice. I
havent used RH since version 6.0 came out.
>
> > You never hear about it because really, its the
> > compilers job to do it properly for you. Properly being
> > 'consistantly'.
> I'm reminded of a story from a company I worked for back in college.
> The owners told of a bug they encountered early in their development.
> A common optimization for multiplication for powers of two is to
> perform a binary shift. They eventually tracked down their code's
> unpredicable to the fact that their compiler was generating rotate opcodes
> rather than shift opcodes.
>
Oh, I've had programs misbehave when I was over agressive with
optimization flags. Recently it was smpeg. Before that it was SDL.
> Before this toolset migration, I was adding a feature to our bootstrap
> and saw our compiler (Watcom 10a) generate asm which bore no
> reflection to the original source and could not fail to hang the
> processor. gcc and CAD/ul's cc result in similar problems. But all
> is well in each if you turn off the optimization flags.
>
Thats exactly how I got the above to libs to behave. I stopped trying to
optimize the code :)
> > The gcc problem resulted from changes to gcc. THese same problems can
> > happen when you compile the kernel with a different compiler... say egcs
> > or pgcc. They're untested and do things differently than the 'recomended
> > gcc' does.
> >
> > The point of the whole issue was that RH threw away the control. The
> > compiler was a constant. So when there was a bug, was it in the compiler,
> > or in the kernel. It made problems harder to track down.
> >
> > If you want a technical explanation, go search the kernel mailing list.
>
> Lots of complaining there. No real substance. Besides, this thread
> started about compatability between glibc libs. and then wandered into
> bitching about redhat's goof. I've already spent too much time on
> this, so maybe this rant at http://lwn.net/1999/0211/a/monty.html is
> as close as I'll get.
Yeah, yeah, linux sucks.... Real OS's have a kernel debugger....
Check LKML as of about a year ago if you want. LIke I said, this never bit me, I forget the specifics. Its pretty old tho, and long dead.
--
Mental
______________________________________________________________________
Philadelphia Linux Users Group - http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|