gcc-4.8.2-1: /bin/gcc fails

[Yaakov (Cygwin/X)]

On 2013-11-02 04:36, Corinna Vinschen wrote:
> On Nov  1 23:23, David Rothenberger wrote:
>> With gcc-4.8.2-1, the following fails:
>>
>> % touch /tmp/t.c
>> % /bin/gcc -c /tmp/t.c
>> gcc: error: spawn: No such file or directory

Curious, are you seeing real-life references to /bin/gcc?  Because that 
wouldn't be portable anyway.

I did try this on Fedora (recent version of which use /bin => /usr/bin 
and /lib => /usr/lib symlinks) and this worked fine.  AFAICS, the 
difference there is that /usr/bin is the "real" directory and /bin is 
just a symlink, where the reverse is true on Cygwin and a mount is used 
instead of a symlink.

> Uh oh.  That's bad.  Maybe it wasn't such a good idea to switch
> libexecdir from /usr/lib to /usr/libexec?  It breaks applications
> using relative paths to search other application components when
> run from /bin.

AFAIK GCC is unique in this regard; relocatibility code is uncommon, and 
most other uses of libexecdir definitely use absolute paths.

> Either we revert libexecdir to /usr/lib, or we will need to add an
> automount point /libexec -> /usr/libexec as for /bin and /lib.

What if another program references its datadir as ../share/foo?  (I'm 
pretty sure it does happen, although GCC doesn't, FWIW.)  Are you going 
to make an automount point for that as well?  (Didn't think so.) 
Relocatibility simply isn't portable to a /bin == /usr/bin scenarios, 
although use of a symlink instead of a mount might mitigate that.

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.


Yaakov


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