This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc-4.8.2-1: /bin/gcc fails

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


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]