[Glibc-bsd-devel] GNU/kFreeBSD status

[Robert Millan]

On Sat, Jan 24, 2004 at 09:36:49PM -0500, Nathan Hawkins wrote:
> > 
> >   - binutils works again (with ld.so hack, see ldso-hack package)
> 
> Was this recent breakage, or something new I wasn't aware of?

See below.

> >   - Glibc builds again!! I disabled linuxthreads, and changed soname to 0.1.
> >     we're going to use libpth to provide pthreads untill we have a definitive
> >     solution that can be merged in Glibc. People building stuff for
> >     gnu/kfreebsd (sanvila!) should install libc0.1-dev package and start
> >     linking for libc0.1.
> 
> Changing the soname breaks everything. Please don't do that unless it's
> _really_ necessary.

It is, since the ABI has changed. I've managed to allow having both versions
installed in the same system which will permit a safe transition.

Santiago and I have been discussing (by phone) how are we going to do the
transition for the rest of debian packages. It should be harmless once we
are ready to (we need to fix the brk bug first)

> What was wrong with linuxthreads? It's not great, but it seems to work.

linuxthreads is deprecated in upstream. Our final goal may be porting NPTL
or something else, I don't know, but eventualy linuxthreads would stop
working for us. For now, we'll use libpth with pthread emulation. That works
well enough to keep happy all pthread-hunger applications, untill we have
a definitive solution.

> >     Known Glibc bugs:
> >       - sbrk() fails in some/all situations. This breaks bash and possibly
> >       is the reason for gcc and ld diing when put under heavy load. I'm
> >       having a go at this currently.
> 
> Hmm. Haven't seen this at all. Is this specific to the new glibc build
> you're doing, or the old one?

Both are affected. Btw, the problem is a bit clearer now:

  - sbrk() is implemented as a frontend to brk(), which is the broken one.
  - brk() always fails, no matter the parameter, and sets errno = ENOMEM
  - glibc/sysdeps/[...]/kfreebsd/i386/brk.S contradicts that, because it
    doesn't set errno and always returns 0 (xorl %eax, %eax\n ret)

> >       - the resolver is probably broken. I didn't bother to try it, even.
> >       i'll have a look when the other stuff with more priority is fixed
> >       (actualy, perhaps the bug disappears when updating to recent glibc)
> 
> I'd very much like to get this one fixed.

I have applied Bruno's patch, from the link you pasted:

  http://www.cygwin.com/ml/libc-alpha/2002-09/msg00374.html

  (it needed minor change for glibc 2.3)

Yesterday it didn't appear to fix the problem, but (hey!) I just remembered
I tested it with ping, which was linked against libc.so.1 and not libc.so.0.1

Time to try again :)

> I've been busy setting up a
> server based on regular FreeBSD. I'd have been happier if I could have
> used Debian FreeBSD, but a mail server with a broken resolver is pretty
> useless...

By Debian FreeBSD you mean with FreeBSD libc and/or userland? (ala the
former Debian OpenBSD)

If you mean the Glibc-based system, I wouldn't generaly recommend using it for
a production server (okay, I used to run an ftp/apt server on it, but
anyway..).

> >       - ld.so is built as an executable (see sysdeps/[...]/kfreebsd/Makefile)
> >       but this breaks gnu ld. We'll have to discuss the correct solution with
> >       glibc and binutils maintainers.
> 
> I'm not sure what you mean here. Do you mean ldd? IIRC, on Linux, ld.so
> is a shared object, but FreeBSD refuses to execute one. The ldd script
> executes ld.so with the trace feature, and that fails to work. I think
> the problem was solved by linking it as a normal ELF executable.

That's correct (see see sysdeps/[...]/kfreebsd/Makefile)

> I'm not aware of any issues with ld.

Newer versions of gnu ld (from binutils) refuse to link when ld.so is an
executable instead of a shared library. Therefore we should discuss this with
both Glibc and binutils maintainers to find out which out of gnu ld.so.1 or
gnu ld is in fault.

-- 
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T., Ainulindale (Silmarillion)