This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


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

Re: glibc-2.1.91: segfault problem overcome via kludge


Andreas Jaeger <aj@suse.de> writes:
>Adam,

>please send your comments to libc-alpha@sourceware.cygnus.com - I've
>set a CC and Reply-To.  The testers of 2.1.91 will most probably not
>read your comments on bug-glibc.

	Thanks.  I had not seen Ulrich's announcement, but once
you mentioned it to me in a previous email, I found it on dejanews.

	I am surprised that this was placed in the "releases"
directory rather than something like "snapshots."  It might be
a good idea to put the announcement in a README in the releases
directory reduce the number of similar misinterpretations that
other people who did not see the announcement on usenet may make.

	Anyhow, as long as it's built and integrated here, I
will try to put it to some use to generate useful feedback.

> > 	I have overcome the segfaulting problem that I reported
> > earlier tonight by installing each of the .so files with convoluted
> > shell command.

> > 	As far as I can tell, the problem was due an incompatibility
> > between versions of at least one of the .so files that glibc comprises.
> > The problem occured when the new ld-linux.so.2 and libc.so.6 have been
> > installed, but the other .so files have not yet been installed.

>Can you describe the problem better?  What exactly is wrong?  What
>needs to be fixed in glibc?

	The symptom is that some of the commands invoked by "make
install" get a segmentation fault after ld-2.1.91.so and libc-2.1.91.so
(but no other .so files) have been installed.  After that, many other
programs also fail.  The two or three programs that I ran under
gdb (by starting gdb with the old ld-linux.so.2) claimed to experience
their problems at line 255 of nssswitch.c, which, oddly, is a blank
line between the bodies of two subroutines.

	I did not completely figure out the problem, but my guess is
that it may have to do with a change in the error handling mechanism
of dlopen(), and which somehow caused trouble when the old version of
libdl was installed but the new ld-linux.so was already installed.
Things seemed to work OK when I installed everything but ld-linux.so,
and then installed that later.  So, I think this problem can be
worked around by arranging to installing ld-linux.so last, although
a complete diagnosis of the problem could probably enable a cleaner
solution via symbol versioning.

> > 	It is likely that others who build glibc from source but
> > do not track the CVS version will experience the same problem.
> > So, to save everyone time, I have created a binary tar file of
> > the glibc that I rebuilt in the standard way after having done
> > a kludged install.  It is:

> > ftp://ftp.yggdrasil.com/private/adam/glibc-2.1.91.x86.tar.gz

> > 	Any Linux/x86 user running glibc-2.1.3 or earlier who
> > wants to install glibc-2.1.91 from source should do something like
> > the following before doing "make install":
> > 	cd /
> > 	tar xfpvU glibc-2.1.91.x86.tar.gz
> > 	ldconfig

> > 	Note that both the "U" flag in tar and the ldconfig command
> > are vitally important to avoid having an unusable system.  The "U"
> > flag will cause tar to remove files before writing them, so as not
> > to kill the running tar program as its own shared libraries are
> > overwritten.  ldconfig will actually switch to the new libraries.

> > 	After that, it should be safe to build and install the new
> > glibc-2.1.91 from source (you can build without doing an install
> > either before or after installing these binaries).

>Please note that we strongly advise against installing 2.1.91 as your
>primary libc.  Installing 2.1.91 is not safe at all in the moment!

	Having read the announcement, I now understand that.
I will leave the tar file in place in case you folks want to
point testers who are interested in living on the razor's edge
to it.

	I am going to leave glibc-2.1.91 on our build machine and
let the nightly build run, just to see what problems that exposes.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

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