From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22063 invoked by alias); 4 Nov 2013 14:45:20 -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 22052 invoked by uid 89); 4 Nov 2013 14:45:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: out4-smtp.messagingengine.com Received: from Unknown (HELO out4-smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 04 Nov 2013 14:45:17 +0000 Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AC8B820C8C for ; Mon, 4 Nov 2013 09:45:08 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 04 Nov 2013 09:45:08 -0500 Received: from [158.147.136.250] (unknown [158.147.136.250]) by mail.messagingengine.com (Postfix) with ESMTPA id BC5EAC00E95; Mon, 4 Nov 2013 09:45:07 -0500 (EST) Message-ID: <5277B2F3.1060705@cwilson.fastmail.fm> Date: Mon, 04 Nov 2013 14:45:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: The Cygwin Mailing List Subject: Re: gcc-4.8.2-1: /bin/gcc fails References: <52749A63.70803@acm.org> <20131102093635.GB25012@calimero.vinschen.de> <5275D706.5030207@users.sourceforge.net> <20131104114204.GB2731@calimero.vinschen.de> In-Reply-To: <20131104114204.GB2731@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00062.txt.bz2 On 11/4/2013 6:42 AM, Corinna Vinschen wrote: > On Nov 2 23:54, Yaakov (Cygwin/X) wrote: >> 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. My about-to-be-uploaded inetutils update puts the servers in libexecdir aka /usr/libexec/ -- and changes the /etc/defaults/ associated xinetd and inetd.d configuration files as appropriate. 'Course, my to-be-written update announcement will be a horrific, as current users with customized configuration WILL have to modify their files (and setup doesn't have an .rpmsave/.rpmnew mechanism). The currently-distributed version (and associated xinetd scripts and sample inetd.d/ configuration files) puts them in /usr/sbin. If --libexecdir=/usr/lib, then...what? Should I revert to /usr/sbin for slave servers? Use $libexecdir but "know" that it is going to be /usr/lib and configure appropriately? I'm confused as to how to proceed here. Frankly, I've never understood the distinction between / and /usr in a cygwin setup. It makes a certain amount of sense on a "real" OS, but for us? Why not replace the /usr/bin = /bin and /usr/lib = /lib, and the oncoming trainwreck of additional "relocatability" expansions for libexec and share, by simply doing: /usr = / ? Or is there something in windows-land (like shortcuts in the start menu) that would be broken by this? Are we worried about shadowing /etc and /usr/etc (or /home and /usr/home)? -- Chuck -- 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