musl compatibility

[v01dXYZ]

musl has some discrepancies with glibc that causes some issues at compilation/run:

• headers that don't provide the same set of symbols (time.h)
• usage of routines that depends on behaviour left to the implementation by the spec (random). At the end, the program generates very different outputs.

Feel free to suggest the right tags for the commits ([MultiSource], [CLAMR], ...).

[v01dXYZ]

I found a discrepancy related to the way buffered IO is implemented by libc.

#include <stdio.h>
#include <unistd.h>

#define WRITE(fd, str) \
  do { \
  char s[] = str;                               \
  write(fd, s, sizeof(s)); \
  } while (0)

int main(int argc, char **argv)
{
  if(argc < 2) {
    fprintf(stdout, "stdout\n");
    fprintf(stderr, "stderr\n");
  } else {
    WRITE(STDOUT_FILENO, "stdout\n");
    WRITE(STDERR_FILENO, "stderr\n");
  }

  return 0;
}

When you use the following command line, with glibc we have

$ ./buff_io_discrepancy 2>&1 | cat # no argument  -> buffered IO
stderr
stdout
$ ./buff_io_discrepancy direct 2>&1 | cat # argument -> direct IO
stdout
stderr

musl always outputs the same (in this very case at least, I don't know if it holds always true).

This problem appears too with a >out 2>&1.
I don't know how to solves this problem, except by considering using separate reference files for stdout/stderr.

[androm3da]

These changes LGTM but is there someone who should approve them?

[DavidSpickett]

1. This PR has been dormant for a long time, so I want to be careful handling it.
2. For some imported test suites our policy is not to modify the source of the test but to disable it, I don't know how that policy would change with an application. Perhaps we would ideally fix it upstream, if the application is imported from elsewhere.

This is something we should document if we haven't already. @lenary has dealt with this for a test suite before, did we document that decision anywhere? (I would expect it to be in https://llvm.org/docs/TestSuiteGuide.html)

At least we can make that policy clear, even if this PR does not move forward.

Edit: for example obsequi does have a non-CMake change 24139ac, but the majority are CMake changes.

[DavidSpickett]

Just to be clear: being compatible with musl seems like a fine goal if there is a need for it.

[lenary]

Yeah, documenting "what can be changed" vs "what cannot" has not really been done, and I think some changes have crept in to what is effectively vendored code.

I can maybe write a quick note for the docs this afternoon, if that would help.

[androm3da]

Perhaps we would ideally fix it upstream, if the application is imported from elsewhere.

That makes the most sense.

[lenary]

I opened llvm/llvm-project#128937 which I hope adds some clarity about our intentions originally.