Troubles with nptl on Geode

[Khem Raj]

On Tue, Aug 10, 2010 at 7:01 AM, Pirmin Walthert <infos at nappsoft.com> wrote:
> Hello
>
> I'm the developer of a system we use as CPE for our triple-play
> customers. It's based on an ALIX board and since 2 years we are using
> uClibc instead of glibc. After some troubles with callweaver (an
> asterisk fork) and linuxthreads.old our distribution is almost
> "uncrasheable" since 2 years (using the 2.6.27 kernel series until
> december and 2.6.32 since then) after we switched to the new
> linuxthreads implementation. (We also made a stable arm-be port).
>
> In May I started playing with the git-branch and started using nptl. I
> was very surprised that the system was working stable from the first
> moment on (congratulations to the developers!!!). Yesterday I tried to
> update to the newest version and callweaver started to crash on every
> startup!
>
> I've compiled the whole distribution from scratch with several versions
> now and it seems like version 8b48f745be1e086d6e486bbb8167e770f3d1fbc5
> (commit: Choose the correct version for setting up errno) still works
> perfectly while the troubles start to occur with
> c06619d7ab2ebbbc93427ca6a49dcc8d479db549: "nptl: simplify buildsys".
>
> Note that I only looked at the nptl-directory-revisions and didn't
> checkout every version between these commits (however
> c06619d7ab2ebbbc93427ca6a49dcc8d479db549 ist the first commit after
> 8b48f745be1e086d6e486bbb8167e770f3d1fbc5 in the nptl directory).
>
> I'm cross-compiling from a x86-64 system to i586 (TARGET_ARCH="i386" and
> CONFIG_586MMX=y), what should work with AMD Geode LX (and always did in
> the past).
>
> My build-process is: linux-headers, gmp, mpfr, binutils, static gcc
> (because uclibc-nptl needs a minimal cross-compiler for generating the
> headers), uclibc-headers, static gcc agin (don't know if this is
> necessary), uclibc, gcc, busybox, ...
>
> Versions: Kernel 2.6.32.17, gcc-4.3.3, binutils 2.19.1, busybox 1.17.1
>
> Do you have an idea what I'm doing wrong or where the bug could be? I'm
> pretty sure that the build-process is clean and is not using wrong
> headers or similar as even the arm-be cross-compilation succeeded (and
> worked) one year ago, using the same method.
>

can you git bisect for the faulty commit please.

> Best regards,
>
> Pirmin Walthert
>
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>