[Top][All Lists]

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

Re: using make to run binaries

From: David Boyce
Subject: Re: using make to run binaries
Date: Mon, 17 Sep 2007 14:36:53 -0400
User-agent: Thunderbird (Windows/20070728)

Dave Korn wrote:
  So, if you're really sure you're invoking the same executable in both cases,
and that the environment is the same in both cases, and the working directory,
and the command-line options, and the input files, you have a very tricky
problem to solve.  The situation smells like undefined behaviour to me; if
you're using an uninitialised variable or in some other way depending on
random memory contents, that could trigger the different behaviour in your
program.  Your description of the problem is a bit vague, but by "more
chemical information", I'm guessing the library is either returning more
records, or more data fields in each record.  You might yet be able to find
out what's going on by putting strace-alike wrappers around the calls to the
library functions, see if you can verify that the program is driving the
library in the same way with the same calls to the same functions passing the
same arguments in each case.

This technique has never failed me: take the command

        /path/to/binary -i [more args] >

and change it to

        echo /path/to/binary -i [more args]; $(SHELL) -i

Then run make. This will of course print the command you plan to run and leave 
you in an interactive shell with the same exact environment[*], cwd, etc in 
which the command would have run. Now you can run the command via cut-and-paste 
and debug it with all the tools at your disposal. At the very least this should 
take make out of the equation; at this point you should have two windows 
running two interactive shells, producing different output and neither making 
direct use of make. It's hard to believe the problem couldn't be chased down in 
this environment, though you might have to go as far as strace or equivalent.

[*] Some shells will read an additional config file when run in interactive mode. So 
depending on your shell and rc file setup, it's possible for the environment here to 
differ from that of /bin/sh -c "command" which is not interactive. However, you 
say you've already accounted for this concern with previous tests.

-David Boyce

reply via email to

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