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: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 = 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:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=default; bh=QSWx/G5Rj02rucaNXohUOu8nkfs=; b=n8zELvzdQfgA09lsO nlTu2lBUXD2NLeqeRSyRtCmlXTdgb280gKQrPSRt1Y2d5FpT+LbOJA3WXYv+z6XZ kOYVkhmIQdbwDKILL+RjGBHm1sYoCPDYUWaAarX2N76lqJwzLJlGijhNUizwddkK S3RqoeoD6CO34PVCW6/4bTPXnU= 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=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pb0-f54.google.com X-Received: by 10.68.189.101 with SMTP id gh5mr11024166pbc.39.1383454471315; Sat, 02 Nov 2013 21:54:31 -0700 (PDT) Message-ID: <5275D706.5030207@users.sourceforge.net> Date: Sat, 02 Nov 2013 23:54:30 -0500 From: "Yaakov (Cygwin/X)" 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 AT cygwin DOT com Subject: Re: gcc-4.8.2-1: /bin/gcc fails References: <52749A63 DOT 70803 AT acm DOT org> <20131102093635 DOT GB25012 AT calimero DOT vinschen DOT 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