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:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=S0SUTAs0yFRbkE4Q
	2ji0TszHiBQl0Jy/SVEgkQQk1s//aQh+BhONRyt0JBJVohKe67BjiJ3Fn7p7C6/S
	h37nC4RlPnEHwwXp4HhYu/NkqAZqhD/iVEKScP39TV9O2CcVg72VqiFOmR2PkjRX
	KmWkxoYpq4utIjbo7iNXgly76Ho=
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:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=4XVVzo9af53Z3D+fon9Lg3
	xJ5cM=; b=NDTxBNTcK0vS4JQSIIuWl5P7Kya0XPy8hBO+m6DAA5kuIvyvPjzsit
	afV0O1BUU6ox3G30vz98aLSHrjnoc8SuPcaBnkIEjbfAktC0JE2x5lrEwc/pxt5F
	wjmVEorX/OEIAw8M6abY0TNn5W0rpE3BLKvLMCPqxiblvFabCenH8=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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=4.8 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,RDNS_NONE,SPF_SOFTFAIL,URIBL_BLOCKED autolearn=no version=3.3.2
X-HELO: smtpback.ht-systems.ru
Date: Mon, 4 Nov 2013 21:20:44 +0400
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: Andrey Repin <cygwin AT cygwin DOT com>
Message-ID: <3910354883.20131104212044@mtu-net.ru>
To: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>, cygwin AT cygwin DOT com
Subject: Re: gcc-4.8.2-1: /bin/gcc fails
In-Reply-To: <5277B2F3.1060705@cwilson.fastmail.fm>
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> <5277B2F3 DOT 1060705 AT cwilson DOT fastmail DOT fm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Greetings, Charles Wilson!

> 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?

What "slave servers" you're referring to?
The discard/daytime/stuff? They belong to /usr/libexec as per
http://www.linuxbase.org/betaspecs/fhs/fhs.txt as not intended for
manual/direct invocation.

> 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?

Original idea of /usr is to separate "core system" or "strict POSIX" stuff
from "mostly used/user-preferred" stuff. I.e. you may have a standard POSIX
grep in /bin that lack PerlRE support, and "full-featured" grep in /usr/bin.
And no one get hurt.
But, because Cygwin setup is inherently "user", there was no distinction at
any time (at least as long as I remember it).

> 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 = /

That would only mess with the POSIX spirit of the Cygwin. IMHO.

> ?  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)?

This, among other things. Also, circular reference to /usr/usr/usr/usr/usr/...


--
WBR,
Andrey Repin (anrdaemon AT yandex DOT ru) 04.11.2013, <20:52>

Sorry for my terrible english...


--
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