On Thu, Dec 4, 2008 at 11:05 AM, Steve Waltner <[EMAIL PROTECTED]> 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 _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
