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 Mon, Nov 4, 2013 at 10:03 PM, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
>> On Nov  2 23:54, Yaakov (Cygwin/X) wrote:
>>> 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.
>
>> The real life problems is that whether it works or not depends on
>> the path order in $PATH.  That's not exactly transparent to the user.
>
>>> /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.
>
>> Exactly.  The symlink on Fedora gets transparently converted to the
>> realpath(3) /usr/bin, while on Cygwin there are two realpaths due
>> to the mount.
>
> Is this the reason for behavior such as this?
>
> $ which -a test
> /usr/bin/test
> /usr/bin/test
>
> $ mount
> C:/Programs/CygWin/bin on /usr/bin type ntfs (binary,auto)
> C:/Programs/CygWin/lib on /usr/lib type ntfs (binary,auto)
> C:/Programs/CygWin on / type ntfs (binary,auto)
> C:/home on /home type ntfs (binary,noacl,posix=0)
> W: on /var/run type vfat (binary,noacl,posix=0)
> C: on /c type ntfs (binary,noacl,posix=0,noumount,auto)
> Y: on /y type smbfs (binary,noacl,posix=0,noumount,auto)
> Z: on /z type smbfs (binary,noacl,posix=0,noumount,auto)
>
> And there's no junctions from /{bin,lib} to /usr, as I was doing at
> one point.
>
>>> >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.
>
>> The symlink would help, but we would have to create it during
>> installation.  It's ugly, too.
>
>>> 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.
>
> From pure philosophical point, I see reason to make a decision once and for
> all.
> Do you want to invent your own directory structure or follow the one used by
> other *NIX systems?

This is an interesting thread.  The root appears to be the order of
paths that is causing /bin to be chosen over /usr/bin for gcc which
then results in an error from gcc due to the usage of absolute paths
but I'm confused why this is happening at all in the first place.  I
checked the default paths on my installation and I clearly see
/usr/local/bin being looked at before /usr/bin and since there is no
gcc in the first one it will use /usr/bin next.  In fact I don't have
/bin in my path at all.

This is the line defining the default path in /etc/profile.
PATH="/usr/local/bin:/usr/bin:${PATH}"

Robert@Shinji-PC ~
$ which gcc
/usr/bin/gcc

It may of been that /bin was defined in the default path then later
removed but I don't know when.  Otherwise it may of been intentionally
defined by the user at one point for an unknown reason.

Robert Pendell
A perfect world is one of chaos.

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


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