DragonFly BSD
DragonFly commits List (threaded) for 2005-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/sys/sys tls.h src/lib/libc/gen tls.c src/lib/libthread_xu/arch/amd64/amd64 pthread_md.c src/lib/libthread_xu/arch/i386/i386 pthread_md.c src/libexec/rtld-elf rtld.c rtld.h rtld_tls.h src/libexec/rtld-elf/i386 reloc.c

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 28 Mar 2005 08:24:11 -0800 (PST)

:On 28.03.2005, at 05:33, Matthew Dillon wrote:
:>   Log:
:>   Cleanup and retool portions of the TLS support and make sure that
:>   non-threaded binaries remain compatible with older kernels.
:will this make snapshot builds work again? since some days i got 
:invalid syscall faults with pkg_add in nrelease.
:we might consider using a host-pkg_add for that lateron, when we do 
:crossbuilds to other archs.
:   simon

    Hmm.  Yes, before that cleanup libc was doing TLS calls even for
    non-threaded, non-TLS programs, and if such a binary is run on FreeBSD
    or an older version of DragonFly it would fault-out with a non-existant
    system call.

    The buildworld process is supposed to use natively-built binaries for
    the build itself but there are a number of chicken-and-egg issues, such
    as with the compiler, which requires building an architecture-native
    version of the compiler using DragonFly libraries, and that is 
    probably what was causing your problems.

    But this is only delaying the issue.  After the release we are going to
    start working on libc5 and most other libraries will need their major
    revs bumped too, as well as switching to gcc3 and almost certainly using
    static TLS storage natively in the new libraries.  Once we do that there
    is no going back.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]