gcc-4.8.2-1: /bin/gcc fails
Charles Wilson
cygwin@cwilson.fastmail.fm
Mon Nov 4 14:45:00 GMT 2013
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
More information about the Cygwin
mailing list