From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8740 invoked by alias); 3 Nov 2013 04:54:42 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 8725 invoked by uid 89); 3 Nov 2013 04:54:40 -0000 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 Received: from Unknown (HELO mail-pb0-f54.google.com) (209.85.160.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 03 Nov 2013 04:54:39 +0000 Received: by mail-pb0-f54.google.com with SMTP id ro12so403485pbb.13 for ; Sat, 02 Nov 2013 21:54:31 -0700 (PDT) X-Received: by 10.68.189.101 with SMTP id gh5mr11024166pbc.39.1383454471315; Sat, 02 Nov 2013 21:54:31 -0700 (PDT) Received: from [192.168.0.101] (S0106000cf16f58b1.wp.shawcable.net. [24.79.212.134]) by mx.google.com with ESMTPSA id bt1sm19993212pbb.2.2013.11.02.21.54.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 21:54:30 -0700 (PDT) Message-ID: <5275D706.5030207@users.sourceforge.net> Date: Sun, 03 Nov 2013 04:54:00 -0000 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@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 X-SW-Source: 2013-11/txt/msg00041.txt.bz2 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