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=aBcOTujyZrEOFpxhL2b+067ut+58Dc701m8Pwl5rcjl Md2JqtToBlomXggpxJ3hr9UvFudZj4Duf9qPwHknGDoJLXZJWy14jlIAlLr8ri5L joqYZQoWbmQ/Yj+p8QiC+eJLF2g6fGItQc2NxB68oKDVG1ua6OEO04CEMBxlBo4s = 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=u2RiCADYSBpcEuOUbvB+rk9PfCA=; b=vP137CNMUyqDve+Qu RZHe4E1k/NcbcthvxmS7Q+6wYTuwGv9i8Btl9sZabXQ0olvRfkscxPOeTJJMo2nX JCfhvw5SEQtQxd9S67upOuUDozZiaxlcKaIDM1hOZ+yS72txRtNrTIRO7yyEbzFL obtRI+ZoSQZb9VP12ql2IgwYIw= 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=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 Message-ID: <5277B2F3.1060705@cwilson.fastmail.fm> Date: Mon, 04 Nov 2013 09:45:07 -0500 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 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> In-Reply-To: <20131104114204.GB2731@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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