Time for glibc 2.1.2 final?

Time for glibc 2.1.2 final?

[Andreas Jaeger]

Hi,

what open problems do we have for a 2.1.2 release?

I just went over my pile of emails and open reports and classified the 
problems I noticed.  Anything I missed?

Some problems that are not resolved (I don't know how critical they
are (except the crt[ni]. problem):
- The message "Bug in ld-linux 2.1.2pre2 - absolute symbols are
  relocated + Patch" on libc-alpha has not been answered.  Is this
  really a bug?
- the crt[ni].* problem Zack mentioned (this seems to be IMHO the only
  show stopper)
- PR libc/1174: "stdio without SA_RESTART loses output"

I noticed the following cosmetic problems:
- INSTALL is not uptodate (manual/install.texi is more recent)
- FAQ is not uptodate (FAQ.in is more recent)
- Geoff's changes made to FAQ 2.8 in glibc 2.2 should be made to glibc
  2.1 also.

I would like to see glibc 2.1.2 released soon since it fixes three
real FAQs (gcc 2.95 problems, nscd problems (HJ's fix for dns-host.c),
crypt location) - and a number of bug fixes.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: Time for glibc 2.1.2 final?

[Ulrich Drepper]

Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:

> what open problems do we have for a 2.1.2 release?

The db2 patch HJ came up with.  I have only HJ's comment that it works
for him and nothing else.

I also had no chance to build and test the release on Alpha and SPARC.
Scott reported a few problems on Arm (which are fixed) but I don't
know whether this is all.

> - The message "Bug in ld-linux 2.1.2pre2 - absolute symbols are
>   relocated + Patch" on libc-alpha has not been answered.  Is this
>   really a bug?

I don't think so.  If this message comes up it means normally a
corrupted binary.

> - the crt[ni].* problem Zack mentioned (this seems to be IMHO the only
>   show stopper)

This is no problem with the patch I added.  As rth commented, I also
don't believe Zack's words that with the -march=i386 flag properly
used there is a problem.

> - PR libc/1174: "stdio without SA_RESTART loses output"

I haven't found so far a passage in POSIX which would require it
otherwise.  So the answer is likely: Then don't do it.

> I noticed the following cosmetic problems:
> - INSTALL is not uptodate (manual/install.texi is more recent)
> - FAQ is not uptodate (FAQ.in is more recent)

I'll update them when I build it the next time.

> - Geoff's changes made to FAQ 2.8 in glibc 2.2 should be made to glibc
>   2.1 also.

Which changes?

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: Time for glibc 2.1.2 final?

[Andreas Jaeger]

>>>>> Ulrich Drepper writes:

Uli> Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:

>> - Geoff's changes made to FAQ 2.8 in glibc 2.2 should be made to glibc
>> 2.1 also.

Uli> Which changes?

I'm appending them below.

Andreas

--- FAQ.in	Sat Aug 28 06:52:06 1999
+++ ../libc/FAQ.in	Sun Sep  5 19:38:33 1999
@@ -569,7 +573,7 @@
 
 GROUP ( libc.so.6 libc_nonshared.a )
 
-??	When I run an executable on one system which I compiled on
+??excpt	When I run an executable on one system which I compiled on
 	another, I get dynamic linker errors.  Both systems have the same
 	version of glibc installed.  What's wrong?
 
@@ -600,6 +604,24 @@
 problem.  But you nevertheless should use EGCS for other reasons
 (see ?binsize).
 
+{GK} On some Linux distributions for PowerPC, you can see this when you have
+built gcc or egcs from the Web sources (gcc versions 2.95 or earlier), then
+re-built glibc.  This happens because in these versions of gcc, exception
+handling is implemented using an older method; the people making the
+distributions are a little ahead of their time.
+
+A quick solution to this is to find the libgcc.a file that came with the
+distribution (it would have been installed under /usr/lib/gcc-lib), do 
+`ar x libgcc.a frame.o' to get the frame.o file out, and add a line saying
+`LDLIBS-c.so += frame.o' to the file `configparms' in the directory you're
+building in.  You can check you've got the right `frame.o' file by running
+`nm frame.o' and checking that it has the symbols defined that you're
+missing.
+
+This will let you build glibc with the C compiler.  The C++ compiler
+will still be binary incompatible with any C++ shared libraries that
+you got with your distribution.
+
 ??	How can I compile gcc 2.7.2.1 from the gcc source code using
 	glibc 2.x?
 
 
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: Time for glibc 2.1.2 final?

[Joel Klecker]

At 10:54 -0700 1999-09-05, Ulrich Drepper wrote:
>Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:
>> what open problems do we have for a 2.1.2 release?
>
>The db2 patch HJ came up with.  I have only HJ's comment that it works
>for him and nothing else.

Debian has tested the patch on arm and alpha, it works for us.
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL: mailto:jk@espy.org >                 <URL: mailto:espy@debian.org >
<URL: http://web.espy.org/ >               <URL: http://www.debian.org/ >

Re: Time for glibc 2.1.2 final?

[Ulrich Drepper]

Joel Klecker <jk@espy.org> writes:

> Debian has tested the patch on arm and alpha, it works for us.

OK.  Thanks for the update.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: Time for glibc 2.1.2 final?

[Andreas Jaeger]

>>>>> Ulrich Drepper writes:

Uli> Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:
>> what open problems do we have for a 2.1.2 release?

>> - the crt[ni].* problem Zack mentioned (this seems to be IMHO the only
>> show stopper)

Uli> This is no problem with the patch I added.  As rth commented, I also
Uli> don't believe Zack's words that with the -march=i386 flag properly
Uli> used there is a problem.

To double check this, I updated my gcc installation with:
$ /opt/gcc-2.96/bin/gcc -v
Reading specs from /opt/gcc-2.96/lib/gcc-lib/i486-pc-linux-gnu/2.96/specs
gcc version 2.96 19990905 (experimental)

I recompiled the current glibc 2.1.2 with that gcc and got
an error message when trying to execute any binary.  For example:

aj@arthur: 07:07:48 /usr/glibc/src/buildreport/19990905 
$ LD_LIBRARY_PATH=.:elf LD_DEBUG=all elf/ld.so string/tester
11249:  file=string/tester;  generating link map
string/tester: error in loading shared libraries: failed to map segment from shared object: Error 9

I compiled glibc without any special CFLAGS, just with the current CVS 
gcc.

I don't know what's broken here.  Anybody an idea how to debug this?

Has anybody been successfully build glibc with a recent gcc?

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: Time for glibc 2.1.2 final?

[Ulrich Drepper]

Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:

> Uli> This is no problem with the patch I added.  As rth commented, I also
> Uli> don't believe Zack's words that with the -march=i386 flag properly
> Uli> used there is a problem.
> [...]
> I recompiled the current glibc 2.1.2 with that gcc and got
> an error message when trying to execute any binary.  For example:

I have no idea what this is about.  But the problem with crt[in] is
that the compiler generates different code not understood by the
script which leads to lik errors undefined symbols).  Something very
different.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: Time for glibc 2.1.2 final?

[Andreas Jaeger]

>>>>> Ulrich Drepper writes:

Uli> Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:
Uli> This is no problem with the patch I added.  As rth commented, I also
Uli> don't believe Zack's words that with the -march=i386 flag properly
Uli> used there is a problem.
>> [...]
>> I recompiled the current glibc 2.1.2 with that gcc and got
>> an error message when trying to execute any binary.  For example:

Uli> I have no idea what this is about.  But the problem with crt[in] is
Uli> that the compiler generates different code not understood by the
Uli> script which leads to lik errors undefined symbols).  Something very
Uli> different.
Agreed, this looks really different.  Looking at the generated
crt[in], I didn't notice the problems Zack reported either.

The only debugging method that worked is strace, with gdb I didn't get 
any results:-(

$ strace elf/ld.so string/tester
execve("elf/ld.so", ["elf/ld.so", "string/tester"], [/* 36 vars */]) = 0
getuid()                                = 207
getgid()                                = 100
geteuid()                               = 207
getegid()                               = 100
brk(0)                                  = 0x800149d0
brk(0x800159d0)                         = 0x800159d0
open("string/tester", O_RDONLY)         = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=198117, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\220\213"..., 4096) = 4096
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000
getcwd("/usr/glibc/src/buildreport/19990905", 128) = 36
mmap(0x8048000, 36864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, -2147398184, 0) = -1 EBADF (Bad file descriptor)
close(-2147398184)                      = -1 EBADF (Bad file descriptor)
write(2, "string/tester", 13string/tester)           = 13
write(2, ": error in loading shared librar"..., 37: error in loading shared libraries: ) = 37
write(2, "", 0)                         = 0
write(2, "", 0)                         = 0
write(2, "failed to map segment from share"..., 40failed to map segment from shared object) = 40
write(2, ": ", 2: )                       = 2
write(2, "Error 9", 7Error 9)                  = 7
write(2, "\n", 1
)                       = 1
_exit(127)                              = ?

The question is why uses the second mmap call a wrong fd?

After recompiling elf/dl-load.* and elf/dl-minimal.* with gcc 2.95.1,
ld.so segfaulted at a different location.

This looks more like a real compiler bug - but I fear my findings are
not enough to nail this down and get it fixed.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Re: Time for glibc 2.1.2 final?

[Ulrich Drepper]

Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:

> The only debugging method that worked is strace, with gdb I didn't get 
> any results:-(

Take a look at the readelf output:

	readelf -a <binary>

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: Time for glibc 2.1.2 final?

[Geoff Keating]

> From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
> Date: 06 Sep 1999 07:13:54 +0200

> Has anybody been successfully build glibc with a recent gcc?

Well, it works fine for me on powerpc :-).

-- 
Geoffrey Keating <geoffk@cygnus.com>