|
Message-ID: <5726D80C.2000006@landley.net> Date: Sun, 1 May 2016 23:31:08 -0500 From: Rob Landley <rob@...dley.net> To: Rich Felker <dalias@...c.org> Cc: j-core@...ts.j-core.org, musl@...ts.openwall.com Subject: Re: [J-core] updated cross-compiler build system 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.