DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=Y741VNupePEWYjaedbWdxfLPdwY1gYN98VZZuhElkgC
	K76NzUZJiYmsE9hXtjcPksg3UZgd8pI2xJ3CMZaJ31JeaYtQPak8qhZ6Ki7zScjX
	HodkO8XXtTyL3XcqaAA5k+C5dkaEJ+1Rfn4rodV0u6Ce92LavKpL+Mv30oKbnUOA
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <5275D706.5030207@users.sourceforge.net>
Date: Sat, 02 Nov 2013 23:54:30 -0500
From: "Yaakov (Cygwin/X)" <yselkowitz@users.sourceforge.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: gcc-4.8.2-1: /bin/gcc fails
References: <52749A63.70803@acm.org> <20131102093635.GB25012@calimero.vinschen.de>
In-Reply-To: <20131102093635.GB25012@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

I did try this on Fedora (recent version of which use /bin => /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.

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

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.


Yaakov


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