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]

RE: rfc: new libgcc build mechanism


Sort of as a poll: on what systems is the getconf
command not present, and which ones have it but not
in the default path?  Since 
  getconf CS_PATH
is supposed to return the path to the POSIX conforming
shell, if is pervasive enough in reality, then
that might be a way to deal with the "finding
the shell" problem.  (An autoconf-like solution
that looked for getconf would at least be simpler,
in that it doesn't have to qualify the things it
finds by the name of "sh" to any particular spec;
it can just (at least theoretically) believe whatever
getconf tells it.)

Donn
(And... to keep the lawyers happy, reminding you that
I'm speaking only for myself.)

> -----Original Message-----
> From: Robert Lipe [mailto:robertlipe@usa.net]
> Sent: Monday, May 08, 2000 8:13 PM
> To: Donn Terry
> Cc: 'Russ Allbery '; 'autoconf@gnu.org '; 'gcc@gcc.gnu.org '
> Subject: Re: rfc: new libgcc build mechanism
> 
> 
> > the GNU assumption that /bin/sh is the one and only shell
> > leads to a permanent deadlock.  Vendors don't want to break
> > user's existant shell scripts, and there are some corner
> > cases in the Bourne shell that are not completely compatible
> > with a POSIX shell.  Thus, vendors who have taken this route
> > will NEVER (OK... "never say never") replace the Bourne shell
> > (as /bin/sh) with a POSIX shell.  Thus, to the same degree
> 
> This is exactly the problem.  While most (at least most System V's) do
> have a bourne shell that accepts shell functions most vendor /bin/sh
> programs are not the POSIX shell.
> 
> So while most modern systems do have a shell _somewhere_ that 
> meets the
> POSIX standard, the challenge is to find it.  Of course, that could be
> done in an autoconf-like system.
> 
> > Bourne shell.  However, if we ask a different question: can
> > we count on there being a POSIX shell by some name or other
> > (and thus figure out how to find that) then I think there's
> 
> The only two ways that I know of are to look in the documentation that
> the vendor had to file at certification time and to look 
> through a list
> of "well known" locations.
> 
> > no requirement about which directory it lives in (and this
> > is what allows POSIX conformance systems to layer the path
> > such that /bin/sh doesn't change behavior but POSIX conformant
> > applications work).)
> 
> Right.   And it allows it to be "hidden" in a zillion 
> different places.
> Certainly, there is prior art in autoconf roaming the 
> directory tree for
> such things, but it's really icky.
> 
> 
> But my gut tells me that while shell functions are probably "common
> enough" to be used on interesting systems with little pain, 
> the tradoffs
> and paybacks of finding the posix shell will deliver q different value
> equation.
> 
> RJL
> 

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