<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 26 March 2015 at 12:58, Junling Zheng <span dir="ltr"><<a href="mailto:zhengjunling@huawei.com" target="_blank">zhengjunling@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":14o" class="" style="overflow:hidden">This problem is that sometimes the magic.h wouldn't be generated again by <a href="http://magic.h.in" target="_blank">magic.h.in</a> if there<br>
is already an original magic.h, and we may get an unexpected header file.</div></blockquote></div><br><div class="gmail_extra">libmagic_la_SOURCES = magic.c apprentice.c softmagic.c ascmagic.c \</div><div class="gmail_extra"> encoding.c compress.c is_tar.c readelf.c print.c fsmagic.c \</div><div class="gmail_extra"> funcs.c file.h readelf.h tar.h apptype.c \</div><div class="gmail_extra"> file_opts.h elfclass.h mygetopt.h cdf.c cdf_time.c readcdf.c cdf.h</div><div class="gmail_extra"><br></div><div class="gmail_extra">The problem is that the makefile doesn't actually say that the magic binaries depend on magic.h, so make is perfectly reasonably to build the binaries and then re-generate the makefile.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The correct fix here is to add magic.h to libmagic_la_SOURCES.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ross</div></div></div>