[PATCH] file: remove the original magic.h

[PATCH] file: remove the original magic.h

[Junling Zheng]

The magic.h under the src/ directory should be generated by magic.h.in
during compiling. However, if we modify the magic.h.in, we can find that
sometimes the magic.h would not be generated again, and then we use the
original one which is not correct. So remove the original magic.h.

Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
---
 meta/recipes-devtools/file/file_5.22.bb | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb
index 9c6bb38..f4ee31b 100644
--- a/meta/recipes-devtools/file/file_5.22.bb
+++ b/meta/recipes-devtools/file/file_5.22.bb
@@ -22,6 +22,12 @@ inherit autotools
 
 FILES_${PN} += "${datadir}/misc/*.mgc"
 
+do_configure_prepend() {
+	if test -f "${B}/src/magic.h"; then
+		rm -rf ${B}/src/magic.h
+	fi
+}
+
 do_install_append_class-native() {
 	create_cmdline_wrapper ${D}/${bindir}/file \
 		--magic-file ${datadir}/misc/magic.mgc
-- 
1.8.3.4

Re: [PATCH] file: remove the original magic.h

[Richard Purdie]

On Thu, 2015-03-26 at 09:18 +0000, Junling Zheng wrote:
> The magic.h under the src/ directory should be generated by magic.h.in
> during compiling. However, if we modify the magic.h.in, we can find that
> sometimes the magic.h would not be generated again, and then we use the
> original one which is not correct. So remove the original magic.h.
> 
> Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
> ---
>  meta/recipes-devtools/file/file_5.22.bb | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb
> index 9c6bb38..f4ee31b 100644
> --- a/meta/recipes-devtools/file/file_5.22.bb
> +++ b/meta/recipes-devtools/file/file_5.22.bb
> @@ -22,6 +22,12 @@ inherit autotools
>  
>  FILES_${PN} += "${datadir}/misc/*.mgc"
>  
> +do_configure_prepend() {
> +	if test -f "${B}/src/magic.h"; then
> +		rm -rf ${B}/src/magic.h
> +	fi
> +}
> +

If the task checksums change, ${B} should get entirely wiped out with
recent releases of the build system (e.g. dizzy/fido/master). Which
version was this tested and found to be needed with?

Cheers,

Richard

Re: [PATCH] file: remove the original magic.h

[Junling Zheng]

On 2015/3/26 17:54, Richard Purdie wrote:
> On Thu, 2015-03-26 at 09:18 +0000, Junling Zheng wrote:
>> The magic.h under the src/ directory should be generated by magic.h.in
>> during compiling. However, if we modify the magic.h.in, we can find that
>> sometimes the magic.h would not be generated again, and then we use the
>> original one which is not correct. So remove the original magic.h.
>>
>> Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
>> ---
>>  meta/recipes-devtools/file/file_5.22.bb | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb
>> index 9c6bb38..f4ee31b 100644
>> --- a/meta/recipes-devtools/file/file_5.22.bb
>> +++ b/meta/recipes-devtools/file/file_5.22.bb
>> @@ -22,6 +22,12 @@ inherit autotools
>>  
>>  FILES_${PN} += "${datadir}/misc/*.mgc"
>>  
>> +do_configure_prepend() {
>> +	if test -f "${B}/src/magic.h"; then
>> +		rm -rf ${B}/src/magic.h
>> +	fi
>> +}
>> +
> 
> If the task checksums change, ${B} should get entirely wiped out with
> recent releases of the build system (e.g. dizzy/fido/master). Which
> version was this tested and found to be needed with?
> 
> Cheers,
> 
> Richard
> 
This is tested in the Yocto 1.5 poky-dora-10.0.0, which uses the dora branch of oe-core.
But I don't know which version it is actually in oe-core. And I think all branches in
oe-core need this fix.

Should ${B} be replaced by ${S}? Although sometimes they're not the same:)

And I am puzzled why ${B} should be wiped out, and does it be replaced by any other variable
except ${S}?

Cheers,

Junling

Re: [PATCH] file: remove the original magic.h

[Jack Mitchell]

On 26/03/15 11:31, Junling Zheng wrote:
> On 2015/3/26 17:54, Richard Purdie wrote:
>> On Thu, 2015-03-26 at 09:18 +0000, Junling Zheng wrote:
>>> The magic.h under the src/ directory should be generated by magic.h.in
>>> during compiling. However, if we modify the magic.h.in, we can find that
>>> sometimes the magic.h would not be generated again, and then we use the
>>> original one which is not correct. So remove the original magic.h.
>>>
>>> Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
>>> ---
>>>   meta/recipes-devtools/file/file_5.22.bb | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb
>>> index 9c6bb38..f4ee31b 100644
>>> --- a/meta/recipes-devtools/file/file_5.22.bb
>>> +++ b/meta/recipes-devtools/file/file_5.22.bb
>>> @@ -22,6 +22,12 @@ inherit autotools
>>>   
>>>   FILES_${PN} += "${datadir}/misc/*.mgc"
>>>   
>>> +do_configure_prepend() {
>>> +	if test -f "${B}/src/magic.h"; then
>>> +		rm -rf ${B}/src/magic.h
>>> +	fi
>>> +}
>>> +
>> If the task checksums change, ${B} should get entirely wiped out with
>> recent releases of the build system (e.g. dizzy/fido/master). Which
>> version was this tested and found to be needed with?
>>
>> Cheers,
>>
>> Richard
>>
> This is tested in the Yocto 1.5 poky-dora-10.0.0, which uses the dora branch of oe-core.
> But I don't know which version it is actually in oe-core. And I think all branches in
> oe-core need this fix.
>
> Should ${B} be replaced by ${S}? Although sometimes they're not the same:)
>
> And I am puzzled why ${B} should be wiped out, and does it be replaced by any other variable
> except ${S}?
>
> Cheers,
>
> Junling
>

Could this be related to my outstanding bug? There is definitely 
something odd going on around the file magic binary.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=7232

Re: [PATCH] file: remove the original magic.h

[Junling Zheng]

On 2015/3/26 19:58, Jack Mitchell wrote:
> 
> 
> On 26/03/15 11:31, Junling Zheng wrote:
>> On 2015/3/26 17:54, Richard Purdie wrote:
>>> On Thu, 2015-03-26 at 09:18 +0000, Junling Zheng wrote:
>>>> The magic.h under the src/ directory should be generated by magic.h.in
>>>> during compiling. However, if we modify the magic.h.in, we can find that
>>>> sometimes the magic.h would not be generated again, and then we use the
>>>> original one which is not correct. So remove the original magic.h.
>>>>
>>>> Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
>>>> ---
>>>>   meta/recipes-devtools/file/file_5.22.bb | 6 ++++++
>>>>   1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/meta/recipes-devtools/file/file_5.22.bb b/meta/recipes-devtools/file/file_5.22.bb
>>>> index 9c6bb38..f4ee31b 100644
>>>> --- a/meta/recipes-devtools/file/file_5.22.bb
>>>> +++ b/meta/recipes-devtools/file/file_5.22.bb
>>>> @@ -22,6 +22,12 @@ inherit autotools
>>>>     FILES_${PN} += "${datadir}/misc/*.mgc"
>>>>   +do_configure_prepend() {
>>>> +    if test -f "${B}/src/magic.h"; then
>>>> +        rm -rf ${B}/src/magic.h
>>>> +    fi
>>>> +}
>>>> +
>>> If the task checksums change, ${B} should get entirely wiped out with
>>> recent releases of the build system (e.g. dizzy/fido/master). Which
>>> version was this tested and found to be needed with?
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>> This is tested in the Yocto 1.5 poky-dora-10.0.0, which uses the dora branch of oe-core.
>> But I don't know which version it is actually in oe-core. And I think all branches in
>> oe-core need this fix.
>>
>> Should ${B} be replaced by ${S}? Although sometimes they're not the same:)
>>
>> And I am puzzled why ${B} should be wiped out, and does it be replaced by any other variable
>> except ${S}?
>>
>> Cheers,
>>
>> Junling
>>
> 
> Could this be related to my outstanding bug? There is definitely something odd going on around the file magic binary.
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7232
> 
Um, I don't think it is related to your bug...

This problem is that sometimes the magic.h wouldn't be generated again by magic.h.in if there
is already an original magic.h, and we may get an unexpected header file.

Your bug looks like something is lack in your sysroots...

Cheers,

Junling

Re: [PATCH] file: remove the original magic.h

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

On 26 March 2015 at 12:58, Junling Zheng <zhengjunling@huawei.com> wrote:

> This problem is that sometimes the magic.h wouldn't be generated again by
> magic.h.in if there
> is already an original magic.h, and we may get an unexpected header file.
>

libmagic_la_SOURCES = magic.c apprentice.c softmagic.c ascmagic.c \
        encoding.c compress.c is_tar.c readelf.c print.c fsmagic.c \
        funcs.c file.h readelf.h tar.h apptype.c \
        file_opts.h elfclass.h mygetopt.h cdf.c cdf_time.c readcdf.c cdf.h

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.

The correct fix here is to add magic.h to libmagic_la_SOURCES.

Ross

[-- Attachment #2: Type: text/html, Size: 1562 bytes --]

Re: [PATCH] file: remove the original magic.h

[Junling Zheng]

On 2015/3/26 21:08, Burton, Ross wrote:
> 
> On 26 March 2015 at 12:58, Junling Zheng <zhengjunling@huawei.com <mailto:zhengjunling@huawei.com>> wrote:
> 
>     This problem is that sometimes the magic.h wouldn't be generated again by magic.h.in <http://magic.h.in> if there
>     is already an original magic.h, and we may get an unexpected header file.
> 
> 
> libmagic_la_SOURCES = magic.c apprentice.c softmagic.c ascmagic.c \
>         encoding.c compress.c is_tar.c readelf.c print.c fsmagic.c \
>         funcs.c file.h readelf.h tar.h apptype.c \
>         file_opts.h elfclass.h mygetopt.h cdf.c cdf_time.c readcdf.c cdf.h
> 
> 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.
> 
> The correct fix here is to add magic.h to libmagic_la_SOURCES.
> 
> Ross
>
Hi, Ross

I don't think the dependency is the true reason, and I have tested it.

I add the magic.h to libmagic_la_SOURCES, and then make several times.

However, it's disappointing that sometimes the magic.h does still not generated again by the different magic.h.in.

I think the dependency of magic.h for magic binaries has been already declared in Makefile:

BUILT_SOURCES = magic.h
all: $(BUILT_SOURCES)
        $(MAKE) $(AM_MAKEFLAGS) all-am

The following is the comparison of the incorrect and the correct log of compiling:

z00238152@Patch-Test:~>0$ diff -ru log.do_compile.incorrect log.do_compile.correct
--- log.do_compile.incorrect	2015-03-27 11:05:23.000000000 +0800
+++ log.do_compile.correct	2015-03-27 11:09:27.000000000 +0800
@@ -5,6 +5,7 @@
 make[1]: Entering directory `/home/z00238152/halogen/build-fluorine-arma9el-qemu-HULK/tmp-eglibc/work/armv7a-euler-linux-gnueabi/file/5.14-r0/file-5.14'
 Making all in src
 make[2]: Entering directory `/home/z00238152/halogen/build-fluorine-arma9el-qemu-HULK/tmp-eglibc/work/armv7a-euler-linux-gnueabi/file/5.14-r0/file-5.14/src'
+sed -e "s/X.YY/$(echo 5.14 | tr -d .)/" < ../src/magic.h.in > magic.h
 make  all-am
 make[3]: Entering directory `/home/z00238152/halogen/build-fluorine-arma9el-qemu-HULK/tmp-eglibc/work/armv7a-euler-linux-gnueabi/file/5.14-r0/file-5.14/src'

And the Makefile in src directory is the same:

z00238152@Patch-Test:~>0$ diff -ru Makefile.incorrect Makefile.correct
z00238152@Patch-Test:~>0$

And I set the PARALLEL_MAKE ?= "-j 1", the problem also doesn't be fixed.

So I think the true reason is that if the magic.h exists already, sometimes Makefile will not generate it again.

Re: [PATCH] file: remove the original magic.h

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

On 27 March 2015 at 03:31, Junling Zheng <zhengjunling@huawei.com> wrote:

> So I think the true reason is that if the magic.h exists already,
> sometimes Makefile will not generate it again.
>

In that case it's likely entirely down to timestamps.   How are you
modifying magic.h.in?

Ross

[-- Attachment #2: Type: text/html, Size: 726 bytes --]

Re: [PATCH] file: remove the original magic.h

[Junling Zheng]

On 2015/3/27 17:56, Burton, Ross wrote:
> 
> On 27 March 2015 at 03:31, Junling Zheng <zhengjunling@huawei.com <mailto:zhengjunling@huawei.com>> wrote:
> 
>     So I think the true reason is that if the magic.h exists already, sometimes Makefile will not generate it again.
> 
> 
> In that case it's likely entirely down to timestamps.   How are you modifying magic.h.in <http://magic.h.in>?
> 
> Ross
>
Hi, Ross

I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in:

90018fe22ff8b74a22fcd142225b0a00f3f12677
6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67
0056ec32255de1de973574b0300161a1568767d6
09e41625c999a2e5b51e1092f0ef2432a99b5c33
ce90e05774dd77d86cfc8dfa6da57b32816841c4

And the final difference between magic.h and magic.h.in is:

z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h
magic.h     magic.h.in
z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h.in
--- src/magic.h	2015-03-28 02:01:46.000000000 +0000
+++ src/magic.h.in	2015-03-28 02:01:47.000000000 +0000
@@ -74,7 +74,7 @@
 #define	MAGIC_NO_CHECK_FORTRAN	0x000000 /* Don't check ascii/fortran */
 #define	MAGIC_NO_CHECK_TROFF	0x000000 /* Don't check ascii/troff */

-#define MAGIC_VERSION		514	/* This implementation */
+#define MAGIC_VERSION		X.YY	/* This implementation */


 #ifdef __cplusplus
@@ -100,7 +100,12 @@
 int magic_list(magic_t, const char *);
 int magic_errno(magic_t);

-#define MAGIC_PARAM_MAX_RECURSION	0
+#define MAGIC_PARAM_INDIR_MAX		0
+#define MAGIC_PARAM_NAME_MAX		1
+#define MAGIC_PARAM_ELF_PHNUM_MAX	2
+#define MAGIC_PARAM_ELF_SHNUM_MAX	3
+#define MAGIC_PARAM_ELF_NOTES_MAX	4
+
 int magic_setparam(magic_t, int, const void *);
 int magic_getparam(magic_t, int, void *);


So, if Makefile doesn't generate a new magic.h, there will be some "symbol undeclared" errors during compiling.

By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs.

And I think the original magic.h is redundant.

Cheers,

Junling

Re: [PATCH] file: remove the original magic.h

[Richard Purdie]

On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote:
> I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in:
> 
> 90018fe22ff8b74a22fcd142225b0a00f3f12677
> 6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67
> 0056ec32255de1de973574b0300161a1568767d6
> 09e41625c999a2e5b51e1092f0ef2432a99b5c33
> ce90e05774dd77d86cfc8dfa6da57b32816841c4
> 
> And the final difference between magic.h and magic.h.in is:
> 
> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h
> magic.h     magic.h.in
> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h.in
> --- src/magic.h	2015-03-28 02:01:46.000000000 +0000
> +++ src/magic.h.in	2015-03-28 02:01:47.000000000 +0000
> @@ -74,7 +74,7 @@
>  #define	MAGIC_NO_CHECK_FORTRAN	0x000000 /* Don't check ascii/fortran */
>  #define	MAGIC_NO_CHECK_TROFF	0x000000 /* Don't check ascii/troff */
> 
> -#define MAGIC_VERSION		514	/* This implementation */
> +#define MAGIC_VERSION		X.YY	/* This implementation */
> 
> 
>  #ifdef __cplusplus
> @@ -100,7 +100,12 @@
>  int magic_list(magic_t, const char *);
>  int magic_errno(magic_t);
> 
> -#define MAGIC_PARAM_MAX_RECURSION	0
> +#define MAGIC_PARAM_INDIR_MAX		0
> +#define MAGIC_PARAM_NAME_MAX		1
> +#define MAGIC_PARAM_ELF_PHNUM_MAX	2
> +#define MAGIC_PARAM_ELF_SHNUM_MAX	3
> +#define MAGIC_PARAM_ELF_NOTES_MAX	4
> +
>  int magic_setparam(magic_t, int, const void *);
>  int magic_getparam(magic_t, int, void *);
> 
> 
> So, if Makefile doesn't generate a new magic.h, there will be some "symbol undeclared" errors during compiling.
> 
> By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs.
> 
> And I think the original magic.h is redundant.

We ran into this problem in our branches. You need to ensure that your
CVE patches just touch magic.h.in and *not* magic.h. If you do that, the
timestamp of magic.h.in will be more recent that magic.h and your build
will function correctly.

The problem is that patch can patch those two files "at the same time"
on fast machines. You should never patch generated filed in patches in
OE in general.

Cheers,

Richard

Re: [PATCH] file: remove the original magic.h

[Junling Zheng]

On 2015/3/28 16:53, Richard Purdie wrote:
> On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote:
>> I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in:
>>
>> 90018fe22ff8b74a22fcd142225b0a00f3f12677
>> 6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67
>> 0056ec32255de1de973574b0300161a1568767d6
>> 09e41625c999a2e5b51e1092f0ef2432a99b5c33
>> ce90e05774dd77d86cfc8dfa6da57b32816841c4
>>
>> And the final difference between magic.h and magic.h.in is:
>>
>> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h
>> magic.h     magic.h.in
>> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h.in
>> --- src/magic.h	2015-03-28 02:01:46.000000000 +0000
>> +++ src/magic.h.in	2015-03-28 02:01:47.000000000 +0000
>> @@ -74,7 +74,7 @@
>>  #define	MAGIC_NO_CHECK_FORTRAN	0x000000 /* Don't check ascii/fortran */
>>  #define	MAGIC_NO_CHECK_TROFF	0x000000 /* Don't check ascii/troff */
>>
>> -#define MAGIC_VERSION		514	/* This implementation */
>> +#define MAGIC_VERSION		X.YY	/* This implementation */
>>
>>
>>  #ifdef __cplusplus
>> @@ -100,7 +100,12 @@
>>  int magic_list(magic_t, const char *);
>>  int magic_errno(magic_t);
>>
>> -#define MAGIC_PARAM_MAX_RECURSION	0
>> +#define MAGIC_PARAM_INDIR_MAX		0
>> +#define MAGIC_PARAM_NAME_MAX		1
>> +#define MAGIC_PARAM_ELF_PHNUM_MAX	2
>> +#define MAGIC_PARAM_ELF_SHNUM_MAX	3
>> +#define MAGIC_PARAM_ELF_NOTES_MAX	4
>> +
>>  int magic_setparam(magic_t, int, const void *);
>>  int magic_getparam(magic_t, int, void *);
>>
>>
>> So, if Makefile doesn't generate a new magic.h, there will be some "symbol undeclared" errors during compiling.
>>
>> By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs.
>>
>> And I think the original magic.h is redundant.
> 
> We ran into this problem in our branches. You need to ensure that your
> CVE patches just touch magic.h.in and *not* magic.h. If you do that, the
> timestamp of magic.h.in will be more recent that magic.h and your build
> will function correctly.
> 
> The problem is that patch can patch those two files "at the same time"
> on fast machines. You should never patch generated filed in patches in
> OE in general.
> 
> Cheers,
> 
> Richard
>
Hi, Richard

You're right. My CVE patches indeed touch the original magic.h, and that's also why this problem reproduces probabilistic.

I remove the modifying of magic.h in my patches, and this problem seems to be fixed.

However, I still think the origin magic.h is confusing and redundant...:)

Thanks,

Junling

Re: [PATCH] file: remove the original magic.h

[Richard Purdie]

On Sat, 2015-03-28 at 17:37 +0800, Junling Zheng wrote:
> On 2015/3/28 16:53, Richard Purdie wrote:
> > On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote:
> > We ran into this problem in our branches. You need to ensure that your
> > CVE patches just touch magic.h.in and *not* magic.h. If you do that, the
> > timestamp of magic.h.in will be more recent that magic.h and your build
> > will function correctly.
> > 
> > The problem is that patch can patch those two files "at the same time"
> > on fast machines. You should never patch generated filed in patches in
> > OE in general.
> > 
> > Cheers,
> > 
> > Richard
> >
> Hi, Richard
> 
> You're right. My CVE patches indeed touch the original magic.h, and that's also why this problem reproduces probabilistic.
> 
> I remove the modifying of magic.h in my patches, and this problem seems to be fixed.
> 
> However, I still think the origin magic.h is confusing and redundant...:)

There is actually more to this. magic.h is listed as a BUILT_SOURCES
file which means it is not regenerated by the usual dependency magic and
timestamps, only if it doesn't exist or you run make all/check/install.

http://www.gnu.org/software/automake/manual/html_node/Sources.html

So you do need it in your patch however you need to ensure your patch
generates a magic.h which matches magic.h.in.

Cheers,

Richard

Re: [PATCH] file: remove the original magic.h

[Junling Zheng]

On 2015/3/28 19:05, Richard Purdie wrote:
> On Sat, 2015-03-28 at 17:37 +0800, Junling Zheng wrote:
>> On 2015/3/28 16:53, Richard Purdie wrote:
>>> On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote:
>>> We ran into this problem in our branches. You need to ensure that your
>>> CVE patches just touch magic.h.in and *not* magic.h. If you do that, the
>>> timestamp of magic.h.in will be more recent that magic.h and your build
>>> will function correctly.
>>>
>>> The problem is that patch can patch those two files "at the same time"
>>> on fast machines. You should never patch generated filed in patches in
>>> OE in general.
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>> Hi, Richard
>>
>> You're right. My CVE patches indeed touch the original magic.h, and that's also why this problem reproduces probabilistic.
>>
>> I remove the modifying of magic.h in my patches, and this problem seems to be fixed.
>>
>> However, I still think the origin magic.h is confusing and redundant...:)
> 
> There is actually more to this. magic.h is listed as a BUILT_SOURCES
> file which means it is not regenerated by the usual dependency magic and
> timestamps, only if it doesn't exist or you run make all/check/install.
> 
> http://www.gnu.org/software/automake/manual/html_node/Sources.html
> 
> So you do need it in your patch however you need to ensure your patch
> generates a magic.h which matches magic.h.in.
> 
> Cheers,
> 
> Richard
> 
I get it!

Thanks a lot for your detailed explanation:)

Cheers,

Junling