add realpath.c to LIBC_TOP_HALF_MUSL_SOURCES

[dicej]

In #463, I added stubs for statvfs, chmod, etc. and removed the ifdef around the realpath declaration, but neglected to add a realpath implementation. Now we use musl's implementation.

[sbc100]

Providing such stubs does seems like a turnaround in policy for wasi-libc.

Historically we have chosen instead so simply not provide implementations of functions that we don't support, and force downstream users of these functions to instead patch their codebases. I probably should have baught this up in #463.

@sunfishcode I am wrong about my understanding on the status quo? Are we ok making an exception in this one case or are we now OK with stub functions in general?

[dicej]

@sbc100 for context: WebAssembly/wasi-sdk#373 (comment)

[sbc100]

@sbc100 for context: WebAssembly/wasi-sdk#373 (comment)

So its OK to add stubs as long as we plan on implemented them some day? That seem like quite a departure from the previous policy.

I know #373 already landed, so maybe this discussion is simply just too late, but I'm not sure why we shouldn't instead push for a patch to libc++ to avoid depending on functions we can't / don't implement yet. That would seem to fit better with existing policy.

[sunfishcode]

I think a realpath stub makes sense.

In the past I've tended to oppose stubs for things that were simply not implemented. Part of the motivation for this was that we had a lot of wide-open questions about WASI should even be, and what wasi-libc's roll in it should be, and I wanted to err on the side of being conservative. But, I've gotten a variety of feedback that that it often causes more trouble than benefit. And, we have a lot more answers about WASI now.

And in the case of realpath specifically: I've also changed my stance, to supporting the idea that wasi-filesystem switch to being rooted. Assuming we do that, realpath would become something we could fully support. That makes it feel better to have a stub, because we're not saying "this is fundamentally unsupportable, do something else", but "this isn't supported yet".

[kateinoigakukun]

I thought we can just use libc-top-half/musl/src/misc/realpath.c as userland implementation since we already have readlink with cwd emulation, doesn't it work?

[sbc100]

realpath is supposed to set errno when it fails.

I'm not sure which one would make sense here. The man pages says:

ERRORS
       EACCES Read or search permission was denied for a component of the path prefix.

       EINVAL path is NULL.  (Before glibc 2.3, this error is also returned  if  resolved_path  is
              NULL.)

       EIO    An I/O error occurred while reading from the filesystem.

       ELOOP  Too many symbolic links were encountered in translating the pathname.

       ENAMETOOLONG
              A  component  of  a pathname exceeded NAME_MAX characters, or an entire pathname ex‐
              ceeded PATH_MAX characters.

       ENOENT The named file does not exist.

       ENOMEM Out of memory.

       ENOTDIR
              A component of the path prefix is not a directory.

[dicej]

Good catch -- sorry I missed that. I was looking at the RETURN VALUES section of the macOS man page, which didn't mention errno, but I failed to read the ERRORS section. In any case, I've updated this PR to use musl's implementation and removed the stub.

[dicej]

I thought we can just use libc-top-half/musl/src/misc/realpath.c as userland implementation since we already have readlink with cwd emulation, doesn't it work?

Honestly, I assumed it wouldn't, but I just tried adding it to LIBC_TOP_HALF_MUSL_SOURCES and everything built fine, so maybe that's the way to go.

[sbc100]

Oh nice! If that works lgtm

[sunfishcode]

It's cool that this works.