[Glibc-bsd-devel] GNU/kFreeBSD status

[Nathan Hawkins]

On Sun, Jan 25, 2004 at 04:46:51PM +0100, Robert Millan wrote:
> On Sat, Jan 24, 2004 at 09:36:49PM -0500, Nathan Hawkins wrote:
> > 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)

I guess that answers that question, then. ABI breakage is a good reason.

> > 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.

Good luck porting NPTL.

> > >     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)

Hmm. You might want to verify the syscall number, and look at how it's
implemented in the native libc. brk always failing sounds suspiciously
like the wrong syscall, or an obsoleted one.

> > >       - 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..).

Either at this point. Anything but dealing with /usr/ports. 

At this point, I'm seriously considering restarting my native libc port.
glibc still needs major work, and I need something stable that I can use
in production relatively soon.

> > >       - 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.

An alternative might be to link two copies of ld.so, and use the normal
one for everything but ldd.

	---Nathan