Observations/Patch Concerning --prefix Permission Requirements

Jeffrey A Law law@hurl.cygnus.com
Mon Feb 22 01:40:00 GMT 1999


  In message < 19990220152117.5521.qmail@deer >you write:
  > I propose the following patch to clean up some permissions issues
  > "across the wall" between the user doing the build and the user
  > doing the install.  After the ChangeLog entries, a long explanation
  > follows, then the patch itself.
Excellent.  I'm looking forward to being able to flush out a half dozen or
more bugs from my queue related to these problems :-)  Some are
rather old.

  > gcc/ChangeLog:
  > 
  > 	* Makefile.in (all.internal, all.cross): Depend on `doc'
  > 	target, to ensure docs get made before installation.
Yes!


  > gcc/ch/ChangeLog:
  > 
  > 	* Make-lang.in (CHILL.info): Depend on intermediate ch/chill.info
  > 	target instead of the chill.texi file.
  > 	(ch/chill.info): New target, depends on the chill.texi source file.
  > 	Its command writes ch/chill.info instead of chill.info.
  > 	(CHILL.install-info): Install from ch/chill.info instead of
  > 	chill.info.
  > 	If any ch/chill.info* files exist, delete *all* chill.info* files
  > 	in $infodir first, not just the ones corresponding to the
  > 	files to be installed (just in case the docs get smaller).
Seems reasonable.


  > gcc/cp/ChangeLog:
  > 
  > 	* Make-lang.in (cplib2.ready): Don't consider updating
  > 	cplib2 stuff if the current directory isn't writable, as
  > 	it won't work (such as during a `make install').
Similarly.


  > gcc/f/ChangeLog:
  > 
  > 	* Make-lang.in (f77.install-common, f77.install-info,
  > 	f77.install-man, f77.uninstall): Use `$(prefix)/lang-f77'
  > 	instead of `lang-f77' for flag file, to be sure of a
  > 	writable directory, and remove the flag file after each
  > 	operation to keep things clean.
Similarly.

  > There are three directory trees involved:
[ ... ]
Yup.  It all sounds right to me.

  > *Permissions/Access Required By User Doing Build*
  > 
  > Starting with the bootstrap2 phase of the build, the compiler
  > invocation beginning "stage1/xgcc -Bstage1/" includes a -B specification
  > for the *install* directory.
  > 
  > This yields fatal errors if that directory cannot be read due to
  > "permission denied", for example.
Yup.  That would be problematical if the builder can't get at the
install directories in any way shape or form.


  > This might indicate that --prefix identifies not just an *install*
  > directory, but also a directory in which to (potentially) find
  > files and programs supporting the build.  Does anyone know if that's
  > the case -- if there's a design requirement that one or more existing
  > files in the --prefix directory be used during the build process
  > in any configuration?
Yes it is a design requirement that we be able to find things in $prefix
during the build.  That's the preferred way to ensure that gcc finds the
gnu assembler while building -- by having it find the assembler in $prefix/bin.


  > I don't have any patches to offer to "fix" this, at the moment.
  > It's not entirely clear to me this behavior is broken, but I
  > currently lean in that direction.
It's suboptimal behavior.  I don't think we need to try to address it now.


  > *Permissions/Access Required By User Doing Install*
[ ... ]
  > The trickiest problem is g++ wanting to write `gcc/cplib2.new',
  > compare it to `gcc/cplib2.txt' (which is okay, since that's
  > readable), and then touch `gcc/cplib2.ready', all each time a
  > build *or* install -- even after a successfully completed build --
  > is attempted.  This produces apparent fatal errors when the
  > `gcc/' directory cannot be written by the installing user (`giarc').
  > The fix that seems to me most obvious, and least likely to be wrong,
  > is that the test of whether to even try doing these writes should
  > be augmented to require write access to the current directory.
Yea.  Kind of hokey, I've never understood the reasoning behind this.  It's
another thing we should try to clean up when we revamp the build stuff.


  > I think it's too much for egcs 1.1.2, though.
Agreed.

jeff


More information about the Gcc-patches mailing list