Re: Libc-Test: Tests failing on Ubuntu VM

[Max Ruttenberg <mruttenberg@emutechnology.com>]

[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]

Szabolcs,

Thank you! That was helpful. I have a couple of tests that still fail in
functional but they clearly state "64bit tests not implemented."
I still have a bunch of tests that fail in regression though...

Running a make like so:

make CC='/path/to/musl/bin/musl-gcc -Wl,-dynamic-linker=/path/to/
> musl/lib/libc.so'
>

this is what my src/regression/REPORT file looks like:

******************************************************************************************************************************
src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM, got
Operation not permitted
FAIL ./src/regression/malloc-brk-fail-static.exe [status 1]
src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM, got
Operation not permitted
FAIL ./src/regression/malloc-brk-fail.exe [status 1]
src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not permitted
FAIL ./src/regression/malloc-oom-static.exe [status 1]
src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not permitted
FAIL ./src/regression/malloc-oom.exe [status 1]
FAIL ./src/regression/putenv-doublefree-static.exe [signal Segmentation
fault]
FAIL ./src/regression/putenv-doublefree.exe [signal Segmentation fault]
src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not permitted
FAIL ./src/regression/setenv-oom-static.exe [status 1]
src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not permitted
FAIL ./src/regression/setenv-oom.exe [status 1]
******************************************************************************************************************************

Is the brk system call still kosher? I thought malloc was supposed to use
something mmap.


On Wed, Mar 30, 2016 at 12:47 PM, Szabolcs Nagy <nsz@port70.net> wrote:

> * Max Ruttenberg <mruttenberg@emutechnology.com> [2016-03-30 12:18:33
> -0400]:
> > I've built musl on an Ubuntu VM (x86_64 is the architecture) and have
> > installed it to an install directory inside the downloaded clone.
> >
> > So the compiler is in: /path/to/musl/install/bin/musl-gcc
> >
> > The loader is in: /path/to/musl/install/lib/libc.so
> >
> > At the top level of libc-test I run a make like so:
> >
> > make CC=/path/to/musl/bin/musl-gcc RUN_WRAP=/path/to/musl/lib/libc.so
> >
>
> that's not the intended usage
>
> RUN_WRAP is for qemu or similar tools for running the binaries
>
> you can specify the libc.so by changing the dynamic-linker name
> (at least that's enough in case of musl) or installing the
> musl-gcc wrapper/musl based toolchain with different dynamic-linker
> name, e.g.
>
> make CC='/path/to/musl/bin/musl-gcc
> -Wl,-dynamic-linker=/path/to/musl/lib/libc.so'
>
> should work (not tested)
>
> > The tests run, I don't get the "no such file or directory" error. But for
> > some reason a bunch of tests fail that shouldn't according to the
> Libc-Test
> > wiki. What am I doing wrong? Are these tests dependent on system
> resources
> > that maybe I'm not providing e.g. enough memory? Do I need to run as a
> sudo
> > user as might be suggested by the "Operation not permitted" errors?
> >
>
> static linked binaries cannot be loaded by libc.so so all *-static.exe
> failed to run.
>



-Max

[-- Attachment #2: Type: text/html, Size: 4564 bytes --]