This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GCC 3.4.3


----Original Message----
>From: Hugh Sasse Staff Elec Eng
>Sent: 12 April 2005 14:49
 
>>  Wouldn't it be an awful lot easier to just
>> 
>>  A) apply the previously-mentioned fix to toplevel?
> 
> If I knew where it was mentioned, probably.

  Earlier in this very thread, Daniel Jacobowitz said (in reply to Joe Buck,
who had observed the same bug in binutils, and was wondering if it was fixed
yet)

"Yes, since the fix was in the top level.  I have already closed at
least two binutils PRs about this as FIXED - searching for product ==
binutils, subject containing install, state containing RESOLVED would
have shown them."

  This leads pretty directly to PRs 179 and 824, although to be fair on
closer look the discussion attached to PR179 contains the words "patch
posted", and a changelog entry, but no link to the actual patch nor a full
checkin revision log.

http://sourceware.org/bugzilla/show_bug.cgi?id=179

  However the date makes it easy enough to track down in the cvs:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/configure.in?cvsroot=src#rev1.2
43

 
>>  B) use a full path to configure, since this only crops up when using a
>> relative path to the configure script?
> 
> This seems to be what happened in practice, but my :

  <snip long list of dirs1>

> didn't seem to break anything, and the install completed
> successfully.

  Yep, they won't have done any harm.  The bug is that the configure process
uses the path to configure to then generate a relative path to the
install-sh script.  If the original path to configure was absolute, then
this derived path is also absolute, and hence valid for use in any
subdirectory makefile.  In the case where your original path to configure
uses relative directory paths, so does the path that is eventually generated
to install-sh, and that's why it fails in deeper subdirectories: it's no
longer ascending far enough up the tree.  So when you use a full path to
configure, the single copy of install-sh will be invoked through that path,
and there isn't even the slightest possibility of those files being invoked
instead.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]