This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Threading support with glibc 2.2 missing???

----- Original Message -----
From: Eugene Kuznetsov <>
To: Yu Xuanwei <>
Cc: <>
Sent: Wednesday, January 10, 2001 9:17 PM
Subject: Re: Threading support with glibc 2.2 missing???

> Hello Yu,
> Tuesday, January 09, 2001, 8:55:34 PM, you wrote:
> YX> ----- Original Message -----
> YX> From: Eugene Kuznetsov <>
> YX> To: <>
> YX> Sent: Wednesday, January 10, 2001 6:43 AM
> YX> Subject: Threading support with glibc 2.2 missing???
> >> Hello,
> >>
> >>       I was using gdb 5.0 with glibc 2.1.2 ( ix86 Linux ) for a long
> >>  time, and it worked pretty well for me. A few days ago I tried
> >>  to upgrade my system to glibc 2.2, which I supposed to be
> >>  stable. Immediately I discovered that I am no longer able to
> >>  debug anything multithreaded at all - command 'info threads' is
> >>  simply ignored, 'thread' shows information only about thread #0, and
> >>  when program crashes with segfault, I am shown the position where it
> >>  was in starting thread.
> YX> No. GlibC upgrading should be very cautious. GlibC2.0/2.1/2.2 are not
> YX> compitable definitely. If you upgrade GlibC2.0 to GlibC2.1, even some
> YX> commandline instructions will be invalid.
> I didn't notice much problems with new glibc ( except this one ). I
> think that glibc are backward-compatible, am I wrong?

Basicly GlibC is backward-compatible according to official ponit. But from
my experience ponit of view in last few years, we can't believe it too much.
For example, I built my internet mail application for GlibC2.0. When I
upgrade to 2.1, weird: the mail application can't not manipulate
getnamebyhost( )! So problem is not always obvious. 100% compatibility is a
dream but not a reality.

Another suffering is that my Linux shell crushed when I install GlibC2.1
into /lib instead of GlibC2.0. I read GLIBC-HOWTO later. This article warns
that you should think it over before you decide to upgrade GlibC.

> >>      I tried compiling sources of gdb from ( I
> >>  suppose it was CVS snapshot from December 15th ). There things only
> >>  gotten worse ( now even 'thread' does not show any meaningful
> >>  information ).
> >>      What am I doing wrong? Is there anything I can do to get
> >>  debugging of multithreaded programs work again ( except reverting to
> >>  glibc 2.1.2/gdb 5.0, of course )?
> YX> Since you changed your basic system library, the conservative manner
is to
> YX> rebuild your GDB and other applications. That sounds horrible.
> That was the first thing I did. I tried rebuilding GDB from source,
> rebuilding debugged applications, rebuilding GDB from CVS snapshot.
> Nothing helped. I don't know what else I should rebuild to get it
> working.

So I guess there are some bugs in new distribution.

> At last I just installed back 5.0 from distribution and moved away all
> 2.2-related libs from /lib. Everything works again now ( strange,
> huh? :) ).

After all, I insist that GlibC should not be change boldly. We can't rely on
the compatibility though sometimes the problem is caused by application
bugs. The changing of GlibC offended me times. The conservative way is to
build system for a unique GlibC. I think that's why RedHat is always working
for new distribution.

> --
> Best regards,
>  Eugene                  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]