From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9979 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: [J-core] [musl] updated cross-compiler build system Date: Sun, 1 May 2016 23:31:08 -0500 Message-ID: <5726D80C.2000006@landley.net> References: <20160501054502.GA4059@brightrain.aerifal.cx> <20160501153804.GP22574@port70.net> <20160501171554.GI21636@brightrain.aerifal.cx> <5726965F.1060406@landley.net> <20160502025834.GJ21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1462163496 30189 80.91.229.3 (2 May 2016 04:31:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 May 2016 04:31:36 +0000 (UTC) Cc: j-core@lists.j-core.org, musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-9992-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 02 06:31:28 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ax5W3-0005Me-Lv for gllmg-musl@m.gmane.org; Mon, 02 May 2016 06:31:27 +0200 Original-Received: (qmail 8175 invoked by uid 550); 2 May 2016 04:31:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 8149 invoked from network); 2 May 2016 04:31:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=l6+HsrCpC0tFHiYmGrIoYOkcuAAk6nDy308w4Znbao4=; b=f3WPyc3GUsxjPkdy/VILWLNsMPUU0b+lMXfSrvtMi0OoauD4yDPNoTbCsPVOtz15cf TbLYCnz+IIA8lnjpZ5jDYv2OXsNZIqfOv7FmSgbae3D+rTF9BchzG0HNdVB1iMPZOUMn 4KpJ4MJcO8d/e4KivLG7bk4XcoROodRfy5nWVfQu2E2HiPKSLPgo37d0w4YNhBVE2z61 pzaHygj+hB4XVazvm+sqzLfNKHqN4EAuVTN8jo1+RW1HeJeY95BCbC5VauAd0tkM0aKa hwsgI8yyr6iNDCZtSP417xzpLcnCMi8B9wbdNszOhqZW33Y3+3VCsFvfb1pWge/Ed4Yw NJ1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=l6+HsrCpC0tFHiYmGrIoYOkcuAAk6nDy308w4Znbao4=; b=BdcI4NqPXia7fnH44cxKpjbZ90ij1kD+/oVXQg8XVtbayu+v+T8ak6PipWliJl6cEt BO/7rbi0gDMrp1E4qhQFUtAiiCCYIQ0+kgqZTLe/CMezcksjz/D6dkNBzue+yvrr+s3M Tq5mf6z370vzmCcXzLB9vvu6xzODNACo+ZccJ4DeBsG7YWWVK6Q9Z/GldgClCMUnv441 nYfY8M9C+CIuVqssqzq/GPCfJO/m+8AcFUZiFOAZq5S9Zzo62EMRpmbiaf0QNE6+Bq5g AMFA661J78Ptu4zQ3D2Uui4cEYFmWngI98oOC0KUWorUEnp/kWNaU+vwcmVEP2biuBZx me9g== X-Gm-Message-State: AOPr4FUxEUCBGO8sgFd4/qtUGC8PRUH52R26kT9lKOBLHjDFxVq3wmR89rXnwkr8Db61wQ== X-Received: by 10.66.65.109 with SMTP id w13mr48181891pas.142.1462163471880; Sun, 01 May 2016 21:31:11 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <20160502025834.GJ21636@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9979 Archived-At: 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