Thanks !

I applied the patch. Still have some tests failing.

For instance tests/buf fails with the following error message:

iconv(&<"abcd">, &<4>, &s, &<3>) caused a SIGSEGV!

I am not sure but  it seems that iconv()  that is called from wrap_iconv() should return  an error return value and set an errno value. 
At least to my understanding  that the way the test is written. 
For musl implementation of iconv()  returns 0 and sets no errno. 

While in the case of standard Linux implementation, errno = E2BIG and -1 returned ( error return value) .

For the case buf linked dynamically against the standard libc.so library:

 ldd tests/buf
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030d1000000)
        librt.so.1 => /lib64/librt.so.1 (0x00000030d4400000)
        libm.so.6 => /lib64/libm.so.6 (0x00000030d0800000)
        libc.so.6 => /lib64/libc.so.6 (0x00000030d0400000)
        /lib64/ld-linux-x86-64.so.2 (0x00000030cf400000)

> uname -a
Linux lnxbdc96 2.6.18-164.11.1.el5 #1 SMP Wed Jan 6 13:26:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

Can you please look into this ? 

Thanks.



On Tue, Apr 23, 2013 at 6:47 PM, Rich Felker <dalias@aerifal.cx> wrote:
On Tue, Apr 23, 2013 at 11:31:27AM -0400, Rich Felker wrote:
> On Tue, Apr 23, 2013 at 06:17:15PM +0300, Timerlan Moldobaev wrote:
> > Can you please specify what  tests within cluts  should  work correctly ?
> > There are chances that in my specific environment some musl issues might
> > pop up even when running cluts partly.
> > I can assist in debugging such issues (as it was for testsuite case).
>
> Yes, I'm actually working on a patch right now that disables the
> incorrect tests and fixes up some other issues.

Here's the patch. I've just disabled the EINTR test module entirely
since it's full of wrong code including broken attempts at
synchronization based on a volatile variable, and attempts to unlock a
lock that's already unlocked.

The other main issue was invalid numeric tests.

Note that the setuid race test will not work without root, and I don't
think it's reliable anyway. There's an alternate test for this issue
on the glibc bug tracker:

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

Rich