Figure out a strategy for testing libzigc against libc-test

[alexrp]

#23529 (comment)

https://wiki.musl-libc.org/libc-test

cc #2879

[rpkak]

#2879 (comment)

rpkak/zig-libc-test

[alexrp]

We talked about this in today's meeting and decided on the following:

• We'll start with a build system option to point to a libc-test checkout. When present, we build and run the tests for all the libc targets we currently test.
• If we're satisfied with that, we'll move on to installing libc-test on the CI machines and enabling the option there.
• If we're satisfied with that after a while, we'll move on to making libc-test a lazy dependency in build.zig.zon.

[alexrp]

We'll start with a build system option to point to a libc-test checkout. When present, we build and run the tests for all the libc targets we currently test.

@rpkak are you interested in tackling this?

[rpkak]

I can try to do this, but I don't have access to all the platforms Zig is targeting. Since some test cases of libc-test are more platform-dependent than others, I think we should try out which tests pass for a specific target with the current libc and deactivate the others.

Also, here is the test suite of wasi-libc, which contains both a subset of the test cases of libc-test and other tests, and mstorsjo/llvm-mingw seems to be what mingw uses for testing.

[alexrp]

That sounds fine; there's certainly going to be some trial and error in figuring out which tests should be enabled where.

[alexrp]

Continuing from here...

I do have a very high file descriptor limit (for some reason):

❯ ulimit -n
1073741816

Memory usage during testing still doesn't get anywhere remotely near OOM levels. But sure enough, if I do ulimit -n 4096, that test passes. I'm not sure exactly which system component gets the blame here, but I suggest we disable this test for now since it's effectively flaky.

#25355