DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=PWlC3BaT5hcmE5EUzQ86jv691k7v/7LSoqejVWekeGXfr/Q4z2Km9
	oRXMXbk5CLPUCYy+K3uEFqRoTVdhEI/NOZ44Xg5cYhjpfiGIYwZnnzu7Bp97YsWe
	UwJ8VfHS0ppqaNmbszwPd8irTiTw0nxE9nN+FFYlxPoPuMiDJdRFRE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 4 Nov 2013 12:42:04 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: gcc-4.8.2-1: /bin/gcc fails
Message-ID: <20131104114204.GB2731@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <52749A63 DOT 70803 AT acm DOT org> <20131102093635 DOT GB25012 AT calimero DOT vinschen DOT de> <5275D706 DOT 5030207 AT users DOT sourceforge DOT net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50"
Content-Disposition: inline
In-Reply-To: <5275D706.5030207@users.sourceforge.net>
User-Agent: Mutt/1.5.21 (2010-09-15)

--hHWLQfXTYDoKhP50
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
>=20
> 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 =3D> /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.
>=20
> AFAIK GCC is unique in this regard; relocatibility code is uncommon,
> and most other uses of libexecdir definitely use absolute paths.
>=20
> >Either we revert libexecdir to /usr/lib, or we will need to add an
> >automount point /libexec -> /usr/libexec as for /bin and /lib.
>=20
> 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 =3D=3D
> /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=3D/usr/lib.

That would be the safer option, I guess.


Corinna

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

--hHWLQfXTYDoKhP50
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSd4gMAAoJEPU2Bp2uRE+gBs4QAKDE/B0mQQNYOflA0sI47C8q
VwoDrCg2JEsl0xz+tMjeRxo82apU6z8AmkTLl7kUzqurvA7DNIr3mBZbEjiqsjnm
el1oF5D30q7HiMX9FgNLTzkIqzjaW6WA70zcE0atm3h2gc52ex6pJGmt2Z+B1jgQ
zDA4jsW6hwUcWtS8xCkCf02ywBrjdxxUWBhZ46BvIa/h96NrFvTuvJQ0MvfbFsCf
9t8EOM/LIHTmtfdOnxo0lvDLp5+ZY99MeF1Uwbo5pODQnVZNJ3goXCyK9T+/3RD2
Og1MrSLsTv15EguKEV3Ju8/pzrb28+OxPvOYJOkI2MpdxJGeeEzYSEyqtQQ3n4gQ
ta9bZ+LGkPXg59QxogEMnq5MJhWtNnIjwA6pvzTStjcAqGDKYU2Hn+3R70I/Kskr
JgxJ4vAtatmzbIPUPZpsPxNUNMOC1FsDSgvrPiUQUPsffnWe6wksbst4ds1a0sbv
4QGuE8sQJuVPhlsYSv5wRlGvG3bpuVh/F7JsMkaby/Q54G2cCoolaa9RGSzcHrrA
xUKv3kWZi9AOumEWl3JYILc/b0rPRjTplZAvzReQbm0raAv1TN/cRpM23JbeUUF9
/f/aU6Do+EaxycxGOMiM/fe2pdQi8VtnS0XK1OZst6APUiXuLqUKiBgQRjq4nCPH
lFzRlXKsr5yP1uvLVpTU
=MqY9
-----END PGP SIGNATURE-----

--hHWLQfXTYDoKhP50--