[J-core] [musl] updated cross-compiler build system

[Rob Landley]

On 05/01/2016 09:58 PM, Rich Felker wrote:
>>> The dep was wrong, but the quoting was intentional, albeit untested.

In bash you can ${blah:-defaultvalue}, but make is crazy.

>>> The idea was to make broken symlinks that would then ENOENT out if the
>>> caller does not want to provide these libs (i.e. wants to use the
>>> system ones). But apparently symlink(2) fails with ENOENT in this
>>> case, so I need a new solution...
>>
>> I don't understand? Your _destination_ must exist. Your source can more
>> or less be an arbitrary string.
> 
> Except the empty string. Linux's symlink(2) fails with ENOENT when the
> source is a zero-length string. I'm skeptical whether this behavior is
> conforming.

Looks like it was introduced in Linux 0.99.7 back in 1993. In my
one-big-repository going back to 0.0.1 it's commit a2a2a154ed6 and the
comment is:

+ * POSIX.1 2.4: an empty pathname is invalid (ENOENT).

Posix says:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html

[ENOENT]
A component of the path prefix of path2 does not name an existing file
or path2 is an empty string.

And this would be also ENOENTing for path1 _and_ path2, but I'm pretty
sure that if Linux has had a historical behavior for 23 years and nobody
cared to correct it, Posix is what's wrong.

NetBSD wasn't sure what to do a few years ago:

https://mail-index.netbsd.org/tech-kern/2013/11/01/msg015865.html

MacOS fsck considers zero length symlinks to be an error in HFS:

https://www.reddit.com/r/applehelp/comments/25h4by/2009_macbook_pro_failing_to_start/

Rob