Re: using make to run binaries

[David Boyce]

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 input.data [more args] > output.data

and change it to

        echo /path/to/binary -i input.data [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