X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:reply-to:message-id:to:subject :in-reply-to:references:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=KfW/L4HgbB6FIxnE D44R0K8jkv1os2fCABY9l+rR8D5+IpvQErYfDkwr1yJ8LFjhZXDzLb954nBx7NwA BQMUUv5qj7izGZ5WCmov1gciCOueN2hmENrPjM4gE+NQGKWhsUsy128rCnQ4KahC Nobk0jeUNNIaB/mydrQJn/ULNfk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:reply-to:message-id:to:subject :in-reply-to:references:mime-version:content-type :content-transfer-encoding; s=default; bh=E3DlTRZ1CA1hWp24OZw62E iO15w=; b=gaksW7ZFVcUiIfVdcztARs9P75OZnvqhxl8JJgkRCFfvjlbXgMdcKv AQzG+Dmax02eiv2t6Yy1wSMDXIJWLcVyzvaokCs7mxdMaIeoz9oeF0/bXW0dPb4L NLXCoCh4VIP+8gNoUm2slgvFMtjzWUIRHMAFSw73tYgdkXEuHCL1g= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.8 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,RDNS_NONE,SPF_SOFTFAIL,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: smtpback.ht-systems.ru Date: Tue, 5 Nov 2013 07:03:11 +0400 From: Andrey Repin Reply-To: Andrey Repin Message-ID: <93705918.20131105070311@mtu-net.ru> To: Corinna Vinschen Subject: Re: gcc-4.8.2-1: /bin/gcc fails In-Reply-To: <20131104114204.GB2731@calimero.vinschen.de> References: <52749A63 DOT 70803 AT acm DOT org> <20131102093635 DOT GB25012 AT calimero DOT vinschen DOT de> <5275D706 DOT 5030207 AT users DOT sourceforge DOT net> <20131104114204 DOT GB2731 AT calimero DOT vinschen DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Greetings, Corinna Vinschen! > On Nov 2 23:54, Yaakov (Cygwin/X) wrote: >> On 2013-11-02 04:36, Corinna Vinschen wrote: >> >On Nov 1 23:23, David Rothenberger wrote: >> >>With gcc-4.8.2-1, the following fails: >> >> >> >>% touch /tmp/t.c >> >>% /bin/gcc -c /tmp/t.c >> >>gcc: error: spawn: No such file or directory >> >> Curious, are you seeing real-life references to /bin/gcc? Because >> that wouldn't be portable anyway. > The real life problems is that whether it works or not depends on > the path order in $PATH. That's not exactly transparent to the user. >> /usr/bin and /lib => /usr/lib symlinks) and this worked fine. >> AFAICS, the difference there is that /usr/bin is the "real" >> directory and /bin is just a symlink, where the reverse is true on >> Cygwin and a mount is used instead of a symlink. > Exactly. The symlink on Fedora gets transparently converted to the > realpath(3) /usr/bin, while on Cygwin there are two realpaths due > to the mount. Is this the reason for behavior such as this? $ which -a test /usr/bin/test /usr/bin/test $ mount C:/Programs/CygWin/bin on /usr/bin type ntfs (binary,auto) C:/Programs/CygWin/lib on /usr/lib type ntfs (binary,auto) C:/Programs/CygWin on / type ntfs (binary,auto) C:/home on /home type ntfs (binary,noacl,posix=0) W: on /var/run type vfat (binary,noacl,posix=0) C: on /c type ntfs (binary,noacl,posix=0,noumount,auto) Y: on /y type smbfs (binary,noacl,posix=0,noumount,auto) Z: on /z type smbfs (binary,noacl,posix=0,noumount,auto) And there's no junctions from /{bin,lib} to /usr, as I was doing at one point. >> >Uh oh. That's bad. Maybe it wasn't such a good idea to switch >> >libexecdir from /usr/lib to /usr/libexec? It breaks applications >> >using relative paths to search other application components when >> >run from /bin. >> AFAIK GCC is unique in this regard; relocatibility code is uncommon, >> and most other uses of libexecdir definitely use absolute paths. >> >> >Either we revert libexecdir to /usr/lib, or we will need to add an >> >automount point /libexec -> /usr/libexec as for /bin and /lib. >> >> What if another program references its datadir as ../share/foo? >> (I'm pretty sure it does happen, although GCC doesn't, FWIW.) Are >> you going to make an automount point for that as well? (Didn't >> think so.) Relocatibility simply isn't portable to a /bin == >> /usr/bin scenarios, although use of a symlink instead of a mount >> might mitigate that. > The symlink would help, but we would have to create it during > installation. It's ugly, too. >> So, while I'm not convinced that this is a huge issue overall, if >> "don't do that" isn't good enough, the easiest workaround is to >> configure GCC with --libexecdir=/usr/lib. > That would be the safer option, I guess. From pure philosophical point, I see reason to make a decision once and for all. Do you want to invent your own directory structure or follow the one used by other *NIX systems? -- WBR, Andrey Repin (anrdaemon AT yandex DOT ru) 05.11.2013, <05:21> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple