[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Make on Linux Feeding All Commands Through ksh

From: Steve Waltner
Subject: Re: GNU Make on Linux Feeding All Commands Through ksh
Date: Wed, 8 Oct 2008 15:13:34 -0500

On Oct 8, 2008, at 1:16 PM, David Boyce wrote:
On Wed, Oct 8, 2008 at 12:31 PM, Steve Waltner <address@hidden> wrote:
- The makefiles include settings like "override SHELL = /bin/ksh" to force
all shell interpretations to go through the ksh.

It appears as though the Linux system feeds every command through a ksh process, while the same function on the Solaris system calls the command
(wether it is a ccpentium, ccarm, or make command) directly.

Are you sure that SHELL = /bin/ksh setting is present on both
platforms? Because the standard behavior of GNU make is to try to
avoid using the shell (to "call the command directly") wherever
possible, *unless* the value of $(SHELL) has been overridden. This is
a good thing, because once the user has swapped in his own shell
there's no way for make to know what its special characters, parsing
rules, etc might be, so it skips the optimization and just throws the
command line at the new value of $(SHELL).

So, regardless of your Solaris/Linux and -j issues, the first mystery
to be solved is why you are not seeing $(SHELL) be executed on
Solaris. Is it possible you're using a strict-POSIX configuration of
Solaris, wherein /bin/sh becomes the POSIX shell aka ksh, and have
become reliant on that?

David Boyce

I'll confess that I'm a little out of my element here. The make process we are using was developed over the last 15 years by a developer that recently left the company. I'm coming in as a System Administrator trying to fix it to where we can deploy Linux build hosts to all users. I do remember the developer saying something about setting $(SHELL) to get things parsed properly, but I don't know the details on why that was necessary.

From what I've gathered, SHELL is always set to /bin/ksh. There are a couple ifeq/ifneq checks in the makefiles to define things differently on Linux and Solaris, but I haven't traced how those could be wrapped around the definitions for setting SHELL. To confirm that statement, I edited the rule that spawns the make in each of the sub-directories as follows, which for non-verbose builds has $(Q) set to "@". I added the "echo $(SHELL)" as a debug and this spits out numerous lines saying /bin/ksh when the build is run on either Solaris or Linux, but no blank lines (or /bin/sh lines either), so it appears to me to always be set.

.PHONY: %.make
        echo $(SHELL)
        +$(Q)$(MAKE) \
                -C $(patsubst %/,%,$(dir $@)) \
                $(basename $(notdir $@)) \
                $(subst $(_comma_),$(_space_),$(MKopts)) \
                MKLevel=$$(( $(MKLevel) + 1 ))

I'm not following what your asking in your second paragraph. It sounds like you're suspecting that our Solaris build of GNU make possibly has /bin/ksh as the internal SHELL instead of /bin/sh. I don't believe that is true. In the following output ictgrid004 is a Solaris box and ictgrid005 is the Linux box...

ictgrid004:~> which make
ictgrid004:~> echo $SHELL
ictgrid004:~> make -p | grep SHELL
make: *** No targets specified and no makefile found.  Stop.
SHELL = /bin/sh

ictgrid005:~> which make
ictgrid005:~> echo $SHELL
ictgrid005:~> make -p | grep SHELL
make: *** No targets specified and no makefile found.  Stop.
SHELL = /bin/sh

We don't have anything funny like /bin/sh and /bin/ksh being the same binary either:

ictgrid004:~> \ls -ld /bin /usr/bin/sh /usr/bin/ksh
lrwxrwxrwx   1 root     root           9 Jul 13  2006 /bin -> ./usr/bin
-r-xr-xr-x   3 root     bin       209268 Mar 27  2006 /usr/bin/ksh
-r-xr-xr-x   4 root     root       95480 Mar 25  2006 /usr/bin/sh

ictgrid005:~> \ls -ld /bin /bin/sh /bin/ksh /bin/bash
drwxr-xr-x  2 root root   4096 Sep 30 12:17 /bin
-rwxr-xr-x  1 root root 773184 Apr  1  2008 /bin/bash
-rwxr-xr-x  1 root root 217552 Jun 22  2007 /bin/ksh
lrwxrwxrwx  1 root root      4 Sep 30 10:29 /bin/sh -> bash


reply via email to

[Prev in Thread] Current Thread [Next in Thread]