From: Charles Wilson <cygwin@cwilson.fastmail.fm>
To: The Cygwin Mailing List <cygwin@cygwin.com>
Subject: Re: gcc-4.8.2-1: /bin/gcc fails
Date: Mon, 04 Nov 2013 14:45:00 -0000 [thread overview]
Message-ID: <5277B2F3.1060705@cwilson.fastmail.fm> (raw)
In-Reply-To: <20131104114204.GB2731@calimero.vinschen.de>
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
next prev parent reply other threads:[~2013-11-04 14:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-02 6:23 David Rothenberger
2013-11-02 9:36 ` Corinna Vinschen
2013-11-03 4:54 ` Yaakov (Cygwin/X)
2013-11-03 19:22 ` David Rothenberger
2013-11-04 11:42 ` Corinna Vinschen
2013-11-04 14:45 ` Charles Wilson [this message]
2013-11-04 17:35 ` Andrey Repin
2013-11-05 2:18 ` Yaakov (Cygwin/X)
2013-11-05 9:52 ` Corinna Vinschen
2013-11-05 16:03 ` Charles Wilson
2013-11-05 16:18 ` Corinna Vinschen
2013-11-05 3:05 ` Andrey Repin
2013-11-05 3:39 ` Robert Pendell
2013-11-05 4:20 ` Robert Pendell
2013-11-05 6:35 ` Andrey Repin
2013-11-10 18:08 ` Bengt Larsson
2013-11-22 19:02 ` jojelino
2013-11-22 19:36 ` jojelino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5277B2F3.1060705@cwilson.fastmail.fm \
--to=cygwin@cwilson.fastmail.fm \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).