Re: gcc-4.8.2-1: /bin/gcc fails
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
Re: gcc-4.8.2-1: /bin/gcc fails
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
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
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 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 pgpZUqsR6qz_0.pgp Description: PGP signature
Re: gcc-4.8.2-1: /bin/gcc fails
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 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
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 pgpvdptuQOxhK.pgp Description: PGP signature
Re: gcc-4.8.2-1: /bin/gcc fails
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 (anrdae...@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
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
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
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
Re: gcc-4.8.2-1: /bin/gcc fails
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
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 (anrdae...@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
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
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 pgpDLdt4G2NSl.pgp Description: PGP signature
Re: gcc-4.8.2-1: /bin/gcc fails
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 daver...@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
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
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 pgpTEWUijTcGU.pgp Description: PGP signature
gcc-4.8.2-1: /bin/gcc fails
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 daver...@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