|
From: | David Boyce |
Subject: | Re: using make to run binaries |
Date: | Mon, 17 Sep 2007 14:36:53 -0400 |
User-agent: | Thunderbird 2.0.0.6 (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 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
[Prev in Thread] | Current Thread | [Next in Thread] |