Re: GNU Make on Linux Feeding All Commands Through ksh

[David Boyce]

On Thu, Dec 4, 2008 at 11:05 AM, Steve Waltner <address@hidden> wrote:
> After two months, I'm finally looking into this issue again. Gotta get it
> working by the end of the year since migrating builds to Linux (more
> specifically the faster x86 hardware) is one of my business objectives

Somewhat off topic: Solaris is now FOSS and runs on the same X86
hardware as Linux. Thus there may be good reasons to convert to Linux
but access to faster X86 hardware is not a sufficient one.

I presume you know this and have additional reasons for the switch but
wanted to point it out for the record/archives.

> I do remember
> the developer that did most of the work on the makefiles making the comment
> about /bin/sh on Solaris being junk and switching to /bin/ksh.

That reasoning made sense on Solaris but may have a problem now, given
that you're moving to Linux, because /bin/ksh on Linux is *also* junk.
This stuff is very very tangled and confusing ... briefly, /bin/ksh on
Linux tends to be a link to "pdksh" which is a buggy ksh clone, now
abandoned. The "real" ksh (ksh93) is actually open source too but most
Linux distros won't bundle it due to philosophical issues with its
license (boo). So unless you go out of your way to find and install
the actual ksh package manually you will have a broken ksh on Linux
and a broken /bin/sh on Solaris. Fortunately Solaris has been bundling
bash for quite a long time, so perhaps the most robust and portable
arrangement for you would be to settle on SHELL=/bin/bash.

This may not be related to your problem but might still be a better
plan than the current, and would certainly result in more comparable
behavior.

> The main question that remains would be: Is there a way to debug and follow
> the token check-in/check-out process that is used internally in GNU make to
> try and see what's going on here? I can work on trying to track down what's
> going wrong, but without a way to get visibility into the process, I'd just
> be making random changes to the makefiles, which isn't going to be very
> productive.

Sorry, can't help directly with your main problem since I haven't
worked much with make -j. Since you're building your own make anyway
it shouldn't be too hard to insert some debugging printfs. Or if you
want to be really aggressive you could build a Solaris 10 machine and
install Linux in a "zone" (semi-virtualization concept), then use
dtrace to track what's happening with the job server. Possibly even
strace would help on native Linux.

I don't remember if this was mentioned upthread but presumably you've
read http://make.paulandlesley.org/jobserver.html for background? If
not, probably a good idea.

Hmm... as I think about it, the whole jobserver technique depends on
downstream processes to leave those file descriptors open. If anybody
messes with the FD_CLOEXEC flag or closes them explicitly, you might
see the behavior described. I've seen programs that do something like

   for (i = 3; i < maxfds; i++) close(i);

before an exec, just for the heck of it. I've already mentioned that
pdksh is crap; I wonder if it's doing something like that? Wait, no,
you said you took /bin/ksh out and it still broke ... anyway, I'd try
strace or similar to see if the jobserver pipe's file descriptors are
being closed. Note that this is all based on a memory of the jobserver
document; I have not read it closely, lately.

-David