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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=cZUey1E
	hK1OEKuMG4kHRy8y3gv3gEFlqxLetGCIsy5aUnVzRnDnyY9/wpvx/zAKo/Jc0uHC
	f2D5Q7bfStkM7D31J1gdz3ZkLxF0fzvbFA37O0GbpBVm7QDKtFv6xwe4C2hQNue3
	Asc2kvU3xhqZXKi/7Xi1WRe+QEwCm7b4nQvU=
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:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=cRPx2QJDsYp+O
	JVW0DLL6sJkPfg=; b=pFXS8E+UzRatt1pTpVZUhw0DO5B9NwJB8ZG+lbl+bxXj8
	HDIP0/VPqXAXutltG/fGHGrJCiex2Z9z4xf7ixt/2qWDYE3kAPTDF+TUNTvN7mIE
	PP2CKWS6Wn/cpxiOIXt+CQE1ttKloKMx/DYN67/26akdOn0v5r3vUW+acfwfUk=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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=1.6 required=5.0 tests=BAYES_50,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2
X-HELO:	mail-qc0-f178.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=AuRbQNe8CBVbpcPdPBBmoqagd+2ObZ/xSHT6f27f9jE=; b=LbvoO0UCPswjDvOewFQXTbJrR+mCZ7Gsg2+8CrbwJMtBEofaFVDi9rXBkBykbknOyp 0KdVPMcvYYIyqRfRN5ZFJjhoYl6dO4NfyoZLRkCpkq+77D3rKXi0/C4KV28O78nVsc9v u5GO/hNNG3S72YpQuFRW7zD+whl/tqRazVxb3jjio0E1eJI3olQQzAf6oqGYYBipzR9n +51E1yvshFR5vcRflsp9aqFuVoK4Xd21ir9jkL2iqOR8rITwNSH+ACzfVLgHkZOP1jJr ReMLcHlBxqGaBe9ty78BFefPXd1g6hqyy9fJGGP4BNpfpDsOl89hp2KxOifxcr4qj/Sl dnaQ==
X-Gm-Message-State:	ALoCoQnODvNYqf4l9zZDxwRAzSFdNgBzAym8OWs52Kh855nhSQoj1OdULrf8NUee+wsXsOE3p4W1
X-Received:	by 10.224.98.200 with SMTP id r8mr27034134qan.26.1383622759108; Mon, 04 Nov 2013 19:39:19 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<93705918.20131105070311@mtu-net.ru>
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> <93705918 DOT 20131105070311 AT mtu-net DOT ru>
From:	Robert Pendell <shinji+cygwin AT elite-systems DOT org>
Date:	Mon, 4 Nov 2013 22:38:49 -0500
Message-ID:	<CAAeCd-OBuXdT9NJoaMzw8g4zzXhYWQw_vCvYmefkG-QUy4z5sg@mail.gmail.com>
Subject:	Re: gcc-4.8.2-1: /bin/gcc fails
To:	Andrey Repin <cygwin AT cygwin DOT com>
X-IsSubscribed:	yes

On Mon, Nov 4, 2013 at 10:03 PM, Andrey Repin wrote:
> 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?

This is an interesting thread.  The root appears to be the order of
paths that is causing /bin to be chosen over /usr/bin for gcc which
then results in an error from gcc due to the usage of absolute paths
but I'm confused why this is happening at all in the first place.  I
checked the default paths on my installation and I clearly see
/usr/local/bin being looked at before /usr/bin and since there is no
gcc in the first one it will use /usr/bin next.  In fact I don't have
/bin in my path at all.

This is the line defining the default path in /etc/profile.
PATH="/usr/local/bin:/usr/bin:${PATH}"

Robert AT Shinji-PC ~
$ which gcc
/usr/bin/gcc

It may of been that /bin was defined in the default path then later
removed but I don't know when.  Otherwise it may of been intentionally
defined by the user at one point for an unknown reason.

Robert Pendell
A perfect world is one of chaos.

--
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

- Raw text -