gcc-4.8.2-1: /bin/gcc fails

gcc-4.8.2-1: /bin/gcc fails

[David Rothenberger]

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

This works correctly if gcc is invoked as "gcc" or "/usr/bin/gcc".
It also works correctly with 4.8.1.

It appears this is due to a change from /usr/lib to /usr/libexec.
/bin/gcc attempts to find cc1 under "/bin/../libexec/...". In 4.8.1,
this was "/bin/../lib/...", which works because /lib is mapped to
/usr/lib by Cygwin. /usr/bin/gcc uses "/usr/bin/../libexec" which
also works fine.

I can work around the problem as follows:

% ln -s /libexec /usr/libexec

-- 
David Rothenberger  ----  daveroth@acm.org

"I may be synthetic, but I'm not stupid"
                -- the artificial person, from _Aliens_

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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

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
> 
> This works correctly if gcc is invoked as "gcc" or "/usr/bin/gcc".
> It also works correctly with 4.8.1.
> 
> It appears this is due to a change from /usr/lib to /usr/libexec.
> /bin/gcc attempts to find cc1 under "/bin/../libexec/...". In 4.8.1,
> this was "/bin/../lib/...", which works because /lib is mapped to
> /usr/lib by Cygwin. /usr/bin/gcc uses "/usr/bin/../libexec" which
> also works fine.
> 
> I can work around the problem as follows:
> 
> % ln -s /libexec /usr/libexec

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.

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


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

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

[David Rothenberger]

On 11/2/2013 9:54 PM, 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.

I saw it when building serf, which uses scons. The "cygwin" environment
in scons is derived from the "posix" environment, which sets PATH such
that /bin is before /usr/bin. I've made a new scons release which
reverses this for Cygwin, and that fixes the problem.


-- 
David Rothenberger  ----  daveroth@acm.org

"We will bury you."
                -- Nikita Kruschev

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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

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.

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


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Charles Wilson]

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

--
Chuck


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

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

[Andrey Repin]

Greetings, Charles Wilson!

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

What "slave servers" you're referring to?
The discard/daytime/stuff? They belong to /usr/libexec as per
http://www.linuxbase.org/betaspecs/fhs/fhs.txt as not intended for
manual/direct invocation.

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

Original idea of /usr is to separate "core system" or "strict POSIX" stuff
from "mostly used/user-preferred" stuff. I.e. you may have a standard POSIX
grep in /bin that lack PerlRE support, and "full-featured" grep in /usr/bin.
And no one get hurt.
But, because Cygwin setup is inherently "user", there was no distinction at
any time (at least as long as I remember it).

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

That would only mess with the POSIX spirit of the Cygwin. IMHO.

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

This, among other things. Also, circular reference to /usr/usr/usr/usr/usr/...


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 04.11.2013, <20:52>

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

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

[Yaakov (Cygwin/X)]

On 2013-11-04 08:45, Charles Wilson wrote:
> 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.

Under the circumstances, configuring inetutils with 
--libexecdir=/usr/sbin makes the most sense.


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

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

[Andrey Repin]

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 (anrdaemon@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

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

[Robert Pendell]

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

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

[Robert Pendell]

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

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

[Andrey Repin]

Greetings, Andrey Repin!

> Is this the reason for behavior such as this?

> $ which -a test
> /usr/bin/test
> /usr/bin/test

Hurr... disregard this. It appears, my problem was (is) in /etc/profile, which
forces additional copy of /usr/bin to be injected into $PATH.

Whoever maintain /etc/defaults/..., please strongly consider moving
PATH="/usr/local/bin:/usr/bin:${PATH}"
line to etc/skel/.profile


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 05.11.2013, <10:26>

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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

On Nov  4 20:18, Yaakov (Cygwin/X) wrote:
> On 2013-11-04 08:45, Charles Wilson wrote:
> >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.
> 
> Under the circumstances, configuring inetutils with
> --libexecdir=/usr/sbin makes the most sense.

Full ACK.  Otherwise you'd have to provide some script which tweaks an
existing /etc/inetd.conf to use the new paths.  Possible, but hardly
worth the effort.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Charles Wilson]

On 11/5/2013 4:52 AM, Corinna Vinschen wrote:
> On Nov  4 20:18, Yaakov (Cygwin/X) wrote:
>> Under the circumstances, configuring inetutils with
>> --libexecdir=/usr/sbin makes the most sense.
>
> Full ACK.  Otherwise you'd have to provide some script which tweaks an
> existing /etc/inetd.conf to use the new paths.  Possible, but hardly
> worth the effort.

That's fine for me, but the other servers, maintained by others [1], 
which may or may not by started by inetd/xinetd would also need to 
configure as --libexecdir=/usr/sbin, or THEY would need to tweak 
configurations.

This seems...counter-intuitive. "cygwin follows the LSB and <the stuff> 
goes in /usr/libexec, except when it's too hard so there is the 
following list of exceptions...."  Is that the policy going forward?

I wasn't planning to auto-update config scripts. I was going to update 
the /etc/default/* scripts [2], and then WARN IN BIG LETTERS in the 
announcement that folks will need to manually merge the changes if 
they've modified their configuration files.  I know nobody will read it, 
but when the inevitable queries reach the mailing list I'll be able to 
point to the ANNOUNCE post.

[1] rsh-server, tftp-server, etc.

[2] this is WHY we have an /etc/default/ area after all -- to provide 
updates when configurations OUGHT to change, but without clobbering a 
user's customizations.  The downside, even on GNU/Linux, is that the 
user must manually merge.  Fedora provides tools to help do this, but it 
is still a manual process.

--
Chuck


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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]

On Nov  5 11:02, Charles Wilson wrote:
> On 11/5/2013 4:52 AM, Corinna Vinschen wrote:
> >On Nov  4 20:18, Yaakov (Cygwin/X) wrote:
> >>Under the circumstances, configuring inetutils with
> >>--libexecdir=/usr/sbin makes the most sense.
> >
> >Full ACK.  Otherwise you'd have to provide some script which tweaks an
> >existing /etc/inetd.conf to use the new paths.  Possible, but hardly
> >worth the effort.
> 
> That's fine for me, but the other servers, maintained by others [1],
> which may or may not by started by inetd/xinetd would also need to
> configure as --libexecdir=/usr/sbin, or THEY would need to tweak
> configurations.
> 
> This seems...counter-intuitive. "cygwin follows the LSB and <the
> stuff> goes in /usr/libexec, except when it's too hard so there is
> the following list of exceptions...."  Is that the policy going
> forward?

I can't exactly read Yaakov's brain, but to me the idea here is to
keep the changes for the *user* small and working even after an
update, rather than following the guidelines slavishly.


> I wasn't planning to auto-update config scripts. I was going to
> update the /etc/default/* scripts [2], and then WARN IN BIG LETTERS
> in the announcement that folks will need to manually merge the
> changes if they've modified their configuration files.  I know
> nobody will read it, but when the inevitable queries reach the
> mailing list I'll be able to point to the ANNOUNCE post.
> 
> [1] rsh-server, tftp-server, etc.

rsh-server is your package.

tftp-server *explicitely* installes into /usr/sbin aka --sbindir.

sshd is installed into sbindir as well, btw., and not only on Cygwin,
but upstream.

Looks like there should nothing change, in fact.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Bengt Larsson]

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
>
>This works correctly if gcc is invoked as "gcc" or "/usr/bin/gcc".
>It also works correctly with 4.8.1.
>

I seem to have found something related (in bash, latest gcc):

% touch /tmp/t.c
% PATH=/usr/bin
% gcc -c /tmp/t.c
% PATH=/bin
% gcc -c /tmp/t.c
gcc: error: spawn: No such file or directory
% 

I used to have /bin (not /usr/bin) in my PATH and it used to work.

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

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

[jojelino]

On 2013-11-02 PM 3: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
>
> This works correctly if gcc is invoked as "gcc" or "/usr/bin/gcc".
> It also works correctly with 4.8.1.
>
> It appears this is due to a change from /usr/lib to /usr/libexec.
> /bin/gcc attempts to find cc1 under "/bin/../libexec/...". In 4.8.1,
> this was "/bin/../lib/...", which works because /lib is mapped to
> /usr/lib by Cygwin. /usr/bin/gcc uses "/usr/bin/../libexec" which
> also works fine.
>
> I can work around the problem as follows:
>
> % ln -s /libexec /usr/libexec
>
This problem is caused by zero-byte of 
${builddir}/host-i686-pc-cygwin/specs
and the specs file is created by bootstrapped gcc executable.
the bootstrapped gcc crashes when generating specs file, which is the 
cause of the problem mentioned in this report. the maintainer of gcc 
should have experienced this problem.
to workaround this problem, the package maintainer needed to supress 
C{XX}FLAGS -static-libgcc -static-libstdc++ in 
host-i686-pc-cygwin/gcc/Makefile.
-- 
Regards.


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

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

[jojelino]

On 2013-11-23 AM 4:02, jojelino wrote:
> On 2013-11-02 PM 3:23, David Rothenberger wrote:
> This problem is caused by zero-byte of
> ${builddir}/host-i686-pc-cygwin/specs
> and the specs file is created by bootstrapped gcc executable.
> the bootstrapped gcc crashes when generating specs file, which is the
> cause of the problem mentioned in this report. the maintainer of gcc
> should have experienced this problem.
> to workaround this problem, the package maintainer needed to supress
> C{XX}FLAGS -static-libgcc -static-libstdc++ in
> host-i686-pc-cygwin/gcc/Makefile.

Appending --with-boot-ldflags="   " --with-stage1-ldflags="   " to 
configure argument [1] might work instead of doing nasty stuff to Makefile.

[1] http://gcc.gnu.org/install/configure.html
-- 
Regards.


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