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?
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 05.11.2013, <05:21>
Sorry for my terrible english...
--
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
