This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: gcc-4.8.2-1: /bin/gcc fails
- From: Andrey Repin <anrdaemon at yandex dot ru>
- To: Charles Wilson <cygwin at cwilson dot fastmail dot fm>, cygwin at cygwin dot com
- Date: Mon, 4 Nov 2013 21:20:44 +0400
- Subject: Re: gcc-4.8.2-1: /bin/gcc fails
- Authentication-results: sourceware.org; auth=none
- 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>
- Reply-to: Andrey Repin <cygwin at cygwin dot com>
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@yandex.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