[Snort-devel] Minor snort patch file

Bhagya Bantwal bbantwal at ...402...
Fri Jan 31 11:55:19 EST 2014


John,

Thanks for reporting this and providing a patch. We will look into this
issue.

Thanks,
B


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 2.9.6.0.  I think it's all fairly
> straightforward, except for the change to the makefiles in the target-based
> directory...
>
> 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
> change.
>
> 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
> time.
>
> Enjoy,
> 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.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20140131/e310e138/attachment.html>


More information about the Snort-devel mailing list