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:cc:content-type; q=dns; s=default; b=Y/J3
	Wgp5PWOHKqLXdlOXyJKvyHNeIxJHUKay3wEW8odWXNFTOX+UDjSYOyX3KaUcu7AN
	++HuwwX+ROCNg6hz3Ozz6g/Lf0MJjeQjQxnvL8YFjHOKY+VVboq2XzRwCBo/btxC
	kPfME1cuc38H2NlfYaPHuRUd5LcFnN3L8TpEPOs=
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:cc:content-type; s=default; bh=+NFTLyRe3y
	Au9dSNVlM9ICq9zEE=; b=a0aY2yF9yMNjiX9jD05dtAQAZFcbHF51oO1AnWy7cq
	2GWK82aIsHoSOc5Dmg0rkQ8kdeS8SIbBkFR7Gp1fBSMGC3Z7sW1UbTSPiY7hXN17
	QINHwXPyuWw9kKOQtHqoLbGxbrjbPDDjo5Uc0Y4WbjQTBvlFYfu+vuYARXs9A/h5
	8=
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-qe0-f49.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:cc:content-type;        bh=+3RvaQPvjhYBmJpQxQqrnXsjTvN7r7WBsHyv4A6pCes=;        b=CTEGn2OqhMEaqFVOMDQhlUwX2DEkdEUDJ1YyBnLl/nlimSM7lajqrFXePJeDKMFal4         rpUYz7GBDBT3vaZ8s92eJ+oEU6irLirq4wbulA/VTVZCcI48iXOcgn+6WpctrL2H0PsA         aIput0EQD9BiB0vX+lYkGPJs+Co78zESdCWIzH8crG/kREANnzdzN/uVHnMK05LGfm2B         s6If9MKiHXVsuJ5IeF8Y1woB2SLz6/eEHFZzMOSxYp2R68osKowWCZV5gacSqwngs4wS         xZEiunmkc4uzYauEIbsvnFD5ulLxoaUU01GVtPGF95CLr/9GK2e/n3ohAjKjZrxortKR         z5jQ==
X-Gm-Message-State: ALoCoQno1tHObehVxmDe0QGCVOCxViMbBR1rkaLKLs8dZUSsF35QuaTZL82OVfE2azFpZ1X5jbQS
X-Received: by 10.49.116.210 with SMTP id jy18mr26431858qeb.65.1383625226868; Mon, 04 Nov 2013 20:20:26 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <CAAeCd-OBuXdT9NJoaMzw8g4zzXhYWQw_vCvYmefkG-QUy4z5sg@mail.gmail.com>
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> <CAAeCd-OBuXdT9NJoaMzw8g4zzXhYWQw_vCvYmefkG-QUy4z5sg AT mail DOT gmail DOT com>
From: Robert Pendell <shinji+cygwin AT elite-systems DOT org>
Date: Mon, 4 Nov 2013 23:19:56 -0500
Message-ID: <CAAeCd-OQsktRKKzi_9i4CFKMFtS0qT4HNj6gaO2j630dBoNzcw@mail.gmail.com>
Subject: Re: gcc-4.8.2-1: /bin/gcc fails
To: Robert Pendell <shinji+cygwin AT elite-systems DOT org>
Cc: Andrey Repin <cygwin AT cygwin DOT com>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes

On Mon, Nov 4, 2013 at 10:38 PM, Robert Pendell wrote:
> 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.
>

Actually disregard everything I just said.  I didn't even see the test
case right.  (It's late)  Then got thrown off by the discussion.


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