[Snort-devel] Minor snort patch file
bbantwal at ...402...
Fri Jan 31 11:55:19 EST 2014
Thanks for reporting this and providing a patch. We will look into this
On Thu, Jan 30, 2014 at 11:01 PM, John Eure <john.eure at ...2499...> wrote:
> Hello all,
> Here's a small patch file I've been using, which I thought I'd contribute
> back, in case anyone is interested. It removes the build warnings that
> I've seen, and fixes a few build breaks when using certain configuration
> options, and touches up a few minor incorrect messages that I happened to
> notice. I think some of these have been sent to the list before, but if
> so, they didn't make it into 126.96.36.199. I think it's all fairly
> straightforward, except for the change to the makefiles in the target-based
> The issue was that sometimes, apparently at random, after I had done a
> "make clean" and then one "make", if I did a second "make", it would
> sometimes spontaneously rebuild the "target-based" directory, even though I
> hadn't touched anything inside of it. This only happened on the second
> make after a "make clean", and only some of the time, with no discernable
> pattern to when it would and wouldn't happen.
> I tracked it down, and it's caused by a complicated interaction:
> sf_attribute_table.c is a generated file, and is removed by "make clean",
> but is also included in the distribution, and the build command for
> sf_attribute_table.c has the side effect of building sf_attribute_table.h.
> When combined with the two-pass implementation of make, and my operating
> system's ignorance of fractional seconds, this caused the weird behavior.
> To go into detail: I might do an initial make, which would first detect
> that the .h file needed to be built, and then would build it. Then I'd do
> a "make clean", which would remove the .c and .h files. So far so good.
> Then I'd do my first "make", which would first detect that both files need
> to be rebuilt, and would then build the .h file, and then build the .c
> file. But when it built the .c file, it had the side-effect of also
> rebuilding the .h file, which would overwrite the previously-built .h
> file. So when I'd do my second "make", it would (sometimes) detect that
> the .h file had changed, and thus do another rebuild in the target-based
> directory, even though nothing in there had changed. The "sometimes" is
> because make often runs quickly enough on my build machine that both builds
> of the .h file happen within the same second. Since my OS (Linux kernel
> 2.6.32) ignores fractions of a second when recording file modification
> times, make thinks that the .h file hasn't changed (even if it actually
> has). But if the two builds occur in different seconds, make does detect a
> To eliminate this behavior, I replaced the two make rules with a single
> rule that formally builds both the .h and .c files. I've included a
> commented-out pattern rule which would work for the whole class of .y
> files, assuming that you wouldn't mind using the "sfat_" prefix all the
> John Eure
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> Please visit http://blog.snort.org for the latest news about Snort!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel