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
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <5277B2F3.1060705@cwilson.fastmail.fm>
Date: Mon, 04 Nov 2013 09:45:07 -0500
From: Charles Wilson <cygwin@cwilson.fastmail.fm>
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 <cygwin@cygwin.com>
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

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