From: Robert Pendell <shinji+cygwin@elite-systems.org>
To: Robert Pendell <shinji+cygwin@elite-systems.org>
Cc: Andrey Repin <cygwin@cygwin.com>
Subject: Re: gcc-4.8.2-1: /bin/gcc fails
Date: Tue, 05 Nov 2013 04:20:00 -0000 [thread overview]
Message-ID: <CAAeCd-OQsktRKKzi_9i4CFKMFtS0qT4HNj6gaO2j630dBoNzcw@mail.gmail.com> (raw)
In-Reply-To: <CAAeCd-OBuXdT9NJoaMzw8g4zzXhYWQw_vCvYmefkG-QUy4z5sg@mail.gmail.com>
On Mon, Nov 4, 2013 at 10:38 PM, Robert Pendell wrote:
> 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.
>
Actually disregard everything I just said. I didn't even see the test
case right. (It's late) Then got thrown off by the discussion.
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
next prev parent reply other threads:[~2013-11-05 4:20 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
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 [this message]
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=CAAeCd-OQsktRKKzi_9i4CFKMFtS0qT4HNj6gaO2j630dBoNzcw@mail.gmail.com \
--to=shinji+cygwin@elite-systems.org \
--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).