headers
fche | 1 Jul 2008 16:13
Favicon

new cgen snapshot available

A new automated cgen source snapshot is available
ftp://sources.redhat.com/pub/cgen/snapshots/cgen-20080701.tar.bz2
1477414 bytes, cgen-snapshot-20080701 tag
See also ftp://sources.redhat.com/pub/cgen/snapshots/
Permalink | Reply | 0 comments |
headers
Nick Clifton | 24 Jul 2008 09:46
Picon
Favicon

RFA: Fix the shell used to execute mloop.in

Hi Guys,

  This may be the cause of some derision but I use tcsh as my shell.

  The reason that I bring this up is that I recently encountered a
  problem building the FRV simulator.  It took a while but I tracked
  the problem down to the fact that the genloop.sh script in
  sim/common was invoking the target specific mloop.in script using
  the SHELL from my environment (ie tcsh) rather than the SHELL from
  the makefile that invoked it (ie bash).  Since sim/frv/mloop.in is
  written for sh-style shells using tcsh naturally did not work.  The
  genmloop.sh script does not check for a failed execution of its
  target input file (maybe it should) and the end result was an
  mloop.c file in my sim/frv build directory that was mostly empty.

  So anyway I am proposing the patch below as a solution.  It adds a
  new optional parameter to the genmloop.sh script which specifies the
  shell to use when invoking the target input file.  The I have
  modified the Makefile.in files that use genmloop.sh to pass this
  parameter specifying the shell that they use.

  I tested the patch by rebuilding all of the simulators and
  confirming that I now have a working FRV simulator which can run the
  gcc testsuite.

  There was one other problem that was specific to the FRV.  Its
  mloop.in file was missing a start-of-line-comment character near the
  beginning.  Fixing this one counts as obvious I believe.

  Please may I apply this patch ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 24 Jul 2008 12:13
Picon
Favicon
Gravatar

Re: RFA: Fix the shell used to execute mloop.in

Hi -

On Thu, Jul 24, 2008 at 08:46:04AM +0100, Nick Clifton wrote:

> [...]  So anyway I am proposing the patch below as a solution.  It
> adds a new optional parameter to the genmloop.sh script which
> specifies the shell to use when invoking the target input
> file. [...]

Is there some reason you can't just hard-code SHELL=/bin/sh in
genmloop.sh?

- FChE
Permalink | Reply | 0 comments |
headers
Nick Clifton | 24 Jul 2008 12:20
Picon
Favicon

Re: RFA: Fix the shell used to execute mloop.in

Hi Frank,

> Is there some reason you can't just hard-code SHELL=/bin/sh in
> genmloop.sh?

Because /bin/sh is not the appropriate shell to use on some systems.  (I 
know for example than on some Solaris machines using /bin/zsh is better).

Cheers
   Nick
Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 24 Jul 2008 16:42
Picon
Favicon
Gravatar

Re: RFA: Fix the shell used to execute mloop.in

> >Is there some reason you can't just hard-code SHELL=/bin/sh in
> >genmloop.sh?
> 
> Because /bin/sh is not the appropriate shell to use on some systems.  (I 
> know for example than on some Solaris machines using /bin/zsh is better).

If the associated shell script not compatible with the unix standard
/bin/sh, perhaps that needs to be fixed.

- FChE
Permalink | Reply | 0 comments |
headers
Nick Clifton | 24 Jul 2008 17:14
Picon
Favicon

Re: RFA: Fix the shell used to execute mloop.in

Hi Frank,

>>> Is there some reason you can't just hard-code SHELL=/bin/sh in
>>> genmloop.sh?
>> Because /bin/sh is not the appropriate shell to use on some systems.  (I 
>> know for example than on some Solaris machines using /bin/zsh is better).
> 
> If the associated shell script not compatible with the unix standard
> /bin/sh, perhaps that needs to be fixed.

Oh no, the script is compatible with /bin/sh.  It is just that (if I 
remember correctly) on some earlier versions of Solaris /bin/sh is 
broken and you need to use /bin/zsh instead.

Cheers
   Nick
Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 26 Jul 2008 21:30
Picon
Favicon
Gravatar

Re: RFA: Fix the shell used to execute mloop.in

Nick Clifton <nickc <at> redhat.com> writes:

> Oh no, the script is compatible with /bin/sh.  It is just that (if I
> remember correctly) on some earlier versions of Solaris /bin/sh is
> broken and you need to use /bin/zsh instead.

It would be helpful if you could find some information on this; if
it's only a rumour, or if it only applies to a fifteen-year-old
operating system, maybe it's not worth worrying about it.

- FChE
Permalink | Reply | 0 comments |
headers
Nick Clifton | 29 Jul 2008 13:50
Picon
Favicon

Re: RFA: Fix the shell used to execute mloop.in

Hi Frank,

>> Oh no, the script is compatible with /bin/sh.  It is just that (if I
>> remember correctly) on some earlier versions of Solaris /bin/sh is
>> broken and you need to use /bin/zsh instead.

I was mistaken - I should have said /bin/ksh not /bin/zsh.

> It would be helpful if you could find some information on this; if
> it's only a rumour, or if it only applies to a fifteen-year-old
> operating system, maybe it's not worth worrying about it.

There are some limitations of various shells mentioned here:

http://www.gnu.org/software/libtool/manual/autoconf/Limitations-of-Builtins.html

Essentially though I think that the correct thing to do is to allow the 
user the choice of which shell they are going to use to execute scripts, 
precisely because of the possibility of bugs in the "standard" shell 
they might exist on their host machine.

Cheers
   Nick
Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 29 Jul 2008 14:55
Picon
Favicon
Gravatar

Re: RFA: Fix the shell used to execute mloop.in

Hi -

> [...]  Essentially though I think that the correct thing to do is to
> allow the user the choice of which shell they are going to use to
> execute scripts, precisely because of the possibility of bugs in the
> "standard" shell they might exist on their host machine.

OK, thanks.  If this is the best way of doing that (e.g., better than
environment variables), please go ahead.

- FChE
Permalink | Reply | 0 comments |

Gmane